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Backplane Transceiver Logic (BTL) is widely recognized as . 


a future technology for the next generation computer archi- 
tectures. Invented by National in 1985 to enhance the per- 
formance of backplane buses, BTL makes such buses as 
Futurebus+ and Pl-Bus possible by solving the transmis- 
sion-line problems that limit the speed of buses based on 
the earlier TTL (transistor-transistor logic) technology. 


BTL devices provide today’s densely populated backplanes 
with the increased speed and drive capability they require 
while minimizing any capacitive loading on the bus. Drivers 
use a Schottky diode in series with an open-collector driver 


output to isolate the drive transistor capacitance, minimizing - 


bus loading. 


National’s BTL transceivers have several other advantages 
over their TTL counterparts that further reduce power con- 


sumption and improve system reliability. Most of the power | 


savings come from a reduced voltage swing of 1V on the 


bus, which also reduces the crosstalk on the backplane. © 


The BTL receivers also have precise reference thresholds 
(1.55V +5%) that provide maximum noise immunity. In ad- 
dition, BTL’s incident-wave switching eliminates the settling- 
time delays that slow the performance of the TTL-based 
buses, 


BTL is a proven, accepted interface technology for high- 
speed transmission. The IEEE P1114.1 standard is based 
on National’s BTL technology. This BTL technology has fuel 
several new bus standards for which National has devel- 
oped products: 


DS3875 
ARBITRATION 
CONTROLLER 


0S3883 0S3883 
BTL 9-BIT XCVR BTL 9-BIT XCVR 
0S3885 DS3884 OR 
ARBITRATION} =| HANDSHAKE DS3886 
XCVR XCVR BTL LATCHING 
DATA XCVR 


BTL LATCHING 
DATA XCVR 


COMMAND STATUS 


DS3XXX 
PROTOCOL CONTROLLER 


ADDRESS DATA 


Futurebus+ Chip Set 


Our new Futurebus+ Chip Set includes five devices: two 9- 
bit Data Transceivers (latched and non-latched), a Hand- 
shake Transceiver, an Arbitration Transceiver. and an ipl 
tration Controller. See Figure 7. 


The Futurebus+ standard is a scalable, multi-segmented 
bus architecture that permits the highest data-transfer rate 
possible with the technology available at the time of the 
design. Futurebus+ is capable of data widths from 32 bits 
to 256 bits, addressing widths of 32 and 64 bits, and a data 
transfer rate that scales from 25 megatransfers/second 
(MT/s) today to a projected 100 MT/s. See Figure 2 for 
Futurebus+ Features. 


National advanced BTL devices support all distributed and 
central arbitration implementations of the Futurebus+ ar- 
chitecture, as well as both Compelled and Non-Compelled 
(Packet) Mode of data transfer. ~ 


In either data-transfer mode the DS3883 (unlatched) and/or 
DS3886 (latched) transceivers receive and transmit Ad- 
dress/Data, Data, Parity Command and Status signals. In a 
32-bit system, only six such devices are required, with each 
sending and receiving a byte of information and its associat- 
ed parity bit. A 64-bit system requires just an additional four 
data transceivers per board. The 9-bit BTL Data Transceiver 

- (unlatched or latched) will support the fault-tolerant require- 
ments of Futurebus+ systems. Its architecture is divided 
between eight data bits and one parity bit, and the parity bit 
is used by the system for error detecting/checking and/or 
correction. 


32/64/128/256 BIT DATA PATH 


DS3YYY 
DATA PATH CONTROLLER 


0S3883 


pS3884 BIL 9=BIT DATA XCVR 
HANDSHAKE OR 


XCVR DS3886 
BTL LATCHING DATA XCVR 


4/8/16/32 DEVICES 
(DEPENDING ON DATA= 
PATH WIDTH) 
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FUTUREBUS+ 
BACKPLANE 


TL/F/11162-1 


SYNC SYNC ADDRESS/DATA PATH 


FIGURE 1. National’s Futurebus+ Chip Set Diagram 
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Introduction 


Feature Futurebus+ 
Option 


Bus-Driving X 
Technology 
Data-Path Width 32 to 256 Bits (Data) 
82 to 64 Bits (Address) 
Data-Transfer Compelled Packet 
Protocols 


Arbitration Central and Distributed 


Fault Tolerance Parity Protection 
Live Insertion 
Dual-Bus Support 


Technology 
Independence 
Increased Bus 
Performance 
Upgradeability 
Increased System 
Reliability 
System-Level 
Interoperability 


x 





Message-Passing 


x 
Protocol P 


X 

xX X 
Coherence Support 
Profiles for Bee List Below) 
Target Applications 


Futurebus+ Profiles 

Profile A: Cache-Coherent, System- Bus Architectures 

Profile B: [0 Architectures/Applications 

Profile D: Desktop Computer Applications 

Profile F: High-Performance, Packet-Mode Computer Architectures 
Profiles M1, M2 & M3: Military Applications 

Profile T: Telecommunications Applications 


FIGURE 2. Futurebus+ Features 
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IEEE 
Documentation 


IEEE P1194.1, 
P896.2 

P8961.1, P896.2 
~P896.1,P896.2 
P896.1 

P896.1, P896.2, 
P896.3 

P896.1 


P896.1 


P896.2 





The DS3884 Handshake Transceiver used Futurebus+ 
programmable glitch filters to handle signals that require fil- 
tering out glitches that result from wire-ORing of the bus 
signal lines. We offer both filtered and non-filtered receiver 
outputs to permit optimal performance for broadcast as well 
as single-slave transactions. Three DS3884s are used to 
handle Arbitration Synchronization, Address Synchroniza- 
tion and Data Synchronization signals. 


FILTERED 


ORIVER RECEIVER 


RECEIVER 


6 BITS 6 BITS 


3 BITS 


TL/F/11162-2 
FIGURE 3. DS3884, Handshake Transceiver _ 


The DS3885 Arbitration Transceiver handles all arbitration 
bus lines and implements Futurebus+ contention logic. It’s 
designed to be used with our DS3875 Arbitration Controller. 
By partitioning the arbitration logic between two devices and 
integrating the competition logic into a BTL transceiver, 
we've created the fastest and most cost-effective hardware 
solution. The contention and parity logic are included within 
the DS38885, offering a 30% to 50% improvement in arbitra- 
tion time over other methods. 


WIN/LOSE 


PARITY CHECK 
& : 


BUS STATUS 


ARBITRATION 
& 
COMPARISON 


TL/F/11162-3 
FIGURE 4. DS3885, Arbitration Transceiver 
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The DS3875 Arbitration Controller is capable of implement- 


ing all of the mandatory and optional requirements to the . 
IEEE P896.1 Futurebus+ standard for distributed arbitra- : 


tion, as well as the central arbitration message-passing pro- 
tocol. It interfaces with the bus through the handshake 
transceiver and the arbitration transceiver. In a single chip, 
the DS3875 implements the Futurebus+ arbitration func- 
tion-set specified by the Acquisition, Allocation, and Align- 
ment protocol. A wide range of other functions are also 
managed by the arbitration controller, including user-pro- 
grammable arbitration timing delays, protocol timeouts and 
parity generation, among others. x 

Together, these devices in the Futurebus+ Chip Set offer 
several built-in advantages designed to satisfy the unique 
demands of high-speed data transmission through densely 
populated buses. All four transceivers are offered in 44-pin 
PLCC and space-saving 44-pin PQFP packages (40-pin 
TapePak® will also be available), and the Arbitration Con- 
troller is offered in a 68-pin PLCC package. | rg 


| 
Pl-Bus = 
The DS1776 Pl-Bus Transceiver was designed to meet 
the low power requirements of the military by combining 
the companies leading BTL experience with an advanced 
BiCMOS process. _ 
National’s patented design and BiCMOS process enable 
the DS1776 to operate at approximately one-fourth the 
power of competing devices. The reduced power consump- 
tion is reflected in the worst-case current (Icc) requirement 
of only 37 mA for the DS1776, compared with 145 mA for 
competing devices. This low power savings can offer up to 
1A-per board savings, reducing the concerns of. avionics 
manufacturers regarding excessive power consumption in 
the limited space available. 


Design Support and Next Genera- 
tion Solutions 


A variety of development tools for BTL and Futurebus+ are 
now available. To start with, this designer’s guide provides 
several new BTL application notes and Futurebus+ system 
application notes. Spice Models and instruction manual of 
BTL Trapezoidal, Turbo, Pl-Bus and Futurebus+ transceiv- 
ers are available upon request along with Verilog® behavior- 
al models. : : 


In anticipation of higher frequencies and even more densely 
populated backplanes, National continues to enhance our 
BTL product line to provide smarter, faster, more highly inte- 
grated interface solutions the computer world demands. As 
a major contributor on the IEEE committee, National’s iden- 
tified several new products, such as standard protocol con- 
trollers for the most popular profiles and processors. In ad- 
dition, several new products will be military-qualified for use 
in the Navy's Next Generation Computer Resources project, 


4 


as well as several other programs. 
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Futurebus + Overview 


David Hawley 


A new standard computer bus with the muscle to match the 
speed of the next generation of 32-bit systems is about to 
bow. Now being balloted by the IEEE, the proposed P896 
Futurebus+ standard promises a maximum data-transfer 
rate ‘of better than 50 million transfers/s, a 500 percent im- 
provement over currént 32-bit buses. What’s more, Future- 
bus+ will be extendable to 256 bits. 


The new bus will offer a lot to system designers. Its ex- 
tremely high data-transfer rate makes it attractive for high- 
performance |/O operations, such as FDDI or high-resolu- 
tion graphics. The fine task scheduling provided by the arbi- 
tration protocol is a requirement for real-time systems. 


Also, its cache coherence, message passing, and split- 
transaction support allow the design of efficient multipro- 
cessing systems. The standard has generated significant 
technological advances throughout its lor g development, 
starting 10 years ago as the original Futurebus. These in- 
clude the creation of Backplane Transceiver Logic to boost 
bus performance, the development of mibicperiormanes 
asynchronous and source-synchronous data-transfer proto- 
cols, ‘and the formulation of a unified theory of cache coher- 
ence. It is currently being examined with great interest by 
the user community as a step beyond the current generation 
of 32-bit TTL standards, such as the VMEbus and Multibus 
ll. As it has the possibility of becoming a universal standard 
bus, it deserves close consideration by anyone designing a 
backplane-based system. 


The performance of Futurebus+ can be expected to vary 
from system to system, depending largely on the data-trans- 
fer mode supported. The. asynchronous, full-handshake 
mode (similar to that of the old Futurebus) uses burst trans- 
fers and can be expected to peak between 20 million and 
25 million transfers/s. A new source-synchronous mode 
should operate at over 50 million transfers/s with the next 
generation of silicon support: Because Futurebus+ sup- 
ports data-path widths of 32, 64, 128, and 256 bits, a raw 
data-transfer rate of 1.6 Gbytes/s is conceivable. Even at 
32 bits, the 200-Mbytes/s source-transfer rate is five times 
the peak of VMEbus or Multibus II. 


The original Futurebus standard was designed by a small 
group of ‘dedicated visionaries without major ‘corporate 
backing. The P896 committee, formed by the IEEE in 1979, 
wanted to create a single industry-standard 32-bit bus for 
multiprocessing systems. By the time the standard was ap- 
proved by the IEEE in 1987, though, the industry-designed 
VME and Multibus I] buses had already established a firm 
hold in the marketplace. 


Reprinted by permission of High Performance System magazine. 
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At the same time, the performance of these buses was be- 
ing stretched to the limit by the new generation of cache- 
based reduced-instruction-set processors. So, rather than 
risk obsolescence, the manufacturers of existing 32-bit sys- 
tems looked for a new platform upon which to develop ap- 
plications. Futurebus was the only high-performance stan- 
dard that could be revised and extended to meet the latest 
system requirements. That’s because there was no large 
base of products already designed to the Futurebus stan- 
dard, and its specs were still pliable. 


The designers of the original Futurebus had already antici- 
pated many of the extensions, such as faster data transfer 
and the caching protocol, and so the process of revising the 
standard went fairly quickly. A number of the changes, how- 
ever, were incompatible with the 1987 version, and so the 
new P896 standard was renamed Futurebus +. Currently in 
ballot are documents covering the mechanical, electrical, 
arbitration, data-transfer, and bus-management layers of 
the specification, as well as the gaching and mesende- ase 
ing protocols. 


Expected to follow in short order are documents on the use 
of Futurebus+ in real-time and high-availability systems 
and those that describe special requirements for industrial 
and military operating environments. Standard bridges are 
also being specified to VMEbus and Multibus II. 


Futurebus+ has been endorsed by vendors of. existing 
32-bit buses, including the VME International Trade Associ- 
ation and the Multibus Manufacturer’s Group. It also has 
been selected by the U.S. Navy as one of the standards for 
future computer contracts. 


The high speed of Futurebus+ is due “ backplane trans- 
ceiver logic, which was first produced by National Semicon- 
ductor in 1984. BTL was designed specifically to drive back- 
plane transmission lines and provides the fastest possible 
bus interface in a CMOS or TTL environment. Its character- 
istics are the foundation upon which the Futurebus + ‘proto- 
col rests. 


BTL devices use open-collector drivers with an output ca- 
pacitance of only 5 pF (possible because the drive transistor 
is isolated from the bus by a series Schottky diode). This 
allows the combined connector, trace, and package capaci- 
tance to be limited to 10 pF for each slot, increasing the 
impedance of the backplane. BTL also operates with a re- 
duced signal swing of only 1V and a precisely controlled 
switching threshold of 1.55V. The result is.that the back- 
plane can be properly terminated at its fully loaded imped- 
ance, while allowing the drivers to cleanly switch the bus 
signals with only 50 mA of drive current. 


\ 





With this interface technology, a bus designer can guaran- 
tee that a signal will cross the input thresholds of every 
receiver on the backplane on the incident edge of the prop- 
agating wavefront. A BTL bus never has to wait for reflec- 
tions to settle before signals can be sampled. This allows 
Futurebus to implement much more efficient and high-per- 
formance data-transfer protocols than any TTL-based com- 
petitor. 


Arbitration 


The Futurebus+ specification carefully works out an arbi- 
tration procedure designed to optimize the scheduling of 
requests from multiple modules and to prevent more than 
one module from trying to transfer data on the bus at the 
same time. Futurebus+ provides a large number of priority 
levels for accurate real-time task scheduling, as well as a 
fairness protocol that allows an even allocation of bus band- 
width to multiple modules. The arbitration takes place on its 
own independent set of lines in parallel with transfers on the 
data bus. The Futurebus arbitration mechanism provides a 
number of other facilities, including error detection and re- 
covery, parking, bus-master identification, emergency mes- 
sages, and a live insertion-and-withdrawal mechanism for 
board replacement in high-availability systems. 


A real-time system requires that task priorities be assigned 
accurately. This guarantees the deadlines of periodic sys- 
tem tasks, decreases the response latency of the system to 
asynchronous events, and ensures that critical tasks will be 
completed even under heavy system loads. In order to 
achieve a high degree of task scheduling, Futurebus+ pro- 
vides up to 8 bits (256 levels) of priority, which can be as- 
signed dynamically to all system tasks. 

In priority arbitration, the competing module with the highest 
priority always wins, and there is no limitation on the fre- 
quency of bus requests. Those modules that are subject to 
real-time constraints can be assigned priorities based on 
the maximum latencies they can tolerate. The only draw- 
back is that modules with low priority may be completely 
shut out during periods of heavy bus usage. However, the 
dynamic allocation capability makes it possible to increase 
the priority of a long-waiting task. 

In most time-sharing multiprocessing systems, though, proc- 
essors need approximately equal access to the bus. If a 
task has been divided among a number of processors, the 
optimum performance results when all the subtasks are 
completed at roughly the same time. Futurebus+ provides 
a round-robin fairness protocol that can operate within each 
priority level. Requests for the system bus at each level are 
serviced in the order of the competing module’s unique ID 
field, typically based on slot position. The round-robin bit is 
set according to the ID of the most recent arbitration winner 
and serves to keep each requesting module’s place in the 
circular queue. This scheme guarantees every module a fair 
slice of the overall bus bandwidth. 


Futurebus+ allows two alternate implementations of this 
arbitration protocol. The first, a central arbitration protocol, 


uses two request lines and one grant line per module. 


These are connected in a star pattern to a central arbiter. 
The priority of each request can be modified to implement 
any of the protocols described above. Arbitration latency will 
be roughly 60 ns in this type of system. 


The second, a distributed protocol is based on an asynchro- 
nous three-wire handshake. This bus handshake controls 
the state machines within each module as they request the 
bus, perform the actual arbitration, check for errors and wait 
for the current bus master to complete its tenure, and trans- 
fer ownership of the bus. Arbitration performance depends 
on the modules participating in the protocol, but can typical- 
ly be expected to range from 150 ns to 350 ns with existing 
technology. 


Most events in a Futurebus+ system are signaled with a 
virtual interrupt mechanism, requiring direct accesses to 
specific memory locations. There are no physical interrupt 
signals in a Futurebus+ backplane, so the arbitration proto- 
col is used to fill this gap. Arbitration messages—special 
arbitration numbers that can be recognized by any module 
in the system—can be used to broadcast interrupts quickly, 
without first obtaining bus mastership or disturbing transfers 
in progress. 


Data Transfer 


Each transaction on Futurebus+ consists of a broadcast 
connection or address transfer, followed by one of a variety 
of data transfer types, and finally a broadcast disconnec- 
tion. The connection phase is used to transmit addresses 
and commands from the master to the slaves, to return 
status to the master from the slaves, and for all participating 
modules to establish their data-transfer capabilities. Those 
modules that.have been selected can participate in the 
data-transfer handshake, as can any caching modules that 
have chosen to “snarf’ (induce data broadcast) or inter- 
vene. The disconnection phase is used to transfer informa- 
tion only during split ttansactions, when it provides the iden- 
tity of the requester and the status of the response. 


There are a number of transfer options that interact dynami- 
cally, providing a transaction set that supports applications 
ranging from the most basic to a multilevel-caching bus hier- 
archy. Transfers typically involve only the master and a sin- 
gle slave. However, because Futurebus+ was designed to 
allow multiple modules to maintain data coherence in 
shared memory environments, the standard also provides 
support for broadcast and intervention (Figure 7). 


Transactions also may be connected or split. The more typi- 
cal is the connected transaction in which all data and status 
information associated with that transaction are returned 
before the address handshake is complete. A split transac- 
tion, in contrast, typically consists of two transfers separat- 
ed in time. 
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Data Transfer (Continued) | 
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4 READ WITH 
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READ 
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MEMORY 


CACHE 


| TWF /N1131=1 


~ FIGURE 1. Futurebus + provides transactions beyond the basic read and write to memory. Efficient multiprocessor 
cache-coherence protocols require that the bus support cache-induced intervention and broadcast. 


The first transfer, a request from the master to the slave, 
may include write data. The second transfer, generated by 
the slave, may include read data. Because both transfers 
are required, the split-transaction protocol is most useful 
during transfers across bus repeaters, where the data- 
access time can be much greater than the arbitration and 
address-transfer overhead. : 


The address/data path on Futurebus+ consists of 32 or 64 
address/data lines on a single connector, with optional ad- 
ditional lines to support 128- or 256-bit data paths, and 8 
user-definable tag bits. Each byte of the address/data high- 
way is protected by a single odd parity bit. There is also a 
8-bit command field (Table I), protected by parity, plus eight 
status lines and three capability lines (Table Il). 


Futurebus+ provides a special set of commands to support 
the higher level cache coherence and split-transaction pro- 
tocols, as shown in Table |. A system that maintains the 
coherence of shared data among multiple modules requires 
that the master let other snooping caches know if it intends 
to keep a copy (share) of the addressed data or if it will write 
(modify) it. Likewise, the other caches must perform certain 
actions if they already have shared or modified copies of 
that data. 


The Futurebus+ data-transfer protocol uses six synchroni- 
zation lines. Three of these, the address-handshake lines, 
are used to establish and break a connection between a 
master and one or more slaves. The other three, the data- 
handshake lines, are used to transfer data or packets be- 
tween the master and those slaves that have established 
the connection. In Futurebus-+ , information is usually trans- 
ferred with every transition of these handshake lines. 





Data Transfer (Continued) 


Single-slave transactions involve only two modules and 
therefore have the most efficient data handshake (Figure 2). 
However, if another slave has an active request for the data 
being transferred—such as a cache with a pending request 
for that data—it can snarf the transaction and turn it into a 
broadcast. In either case, the directly accessed slave may 
not have the most recent copy of the data in a cache sys- 
tem. The cache that has modified the data internally must 
then intervene in the transaction, providing the updated 
data to the master and the selected (and any snarfing) 
slave. 

Futurebus+ also has two distinct data-transfer modes: a 
fully handshaken, asynchronous compelled transfer and a 
high-performance, source-synchronous packet transfer. 
The compelled data-transfer protocol uses an asynchro- 


nous handshake. Information is transferred from the master 
to the slave(s) between the transition of the data strobe and 


TABLE I. Command Lines 


COMMAND LINES 


32- OR 64-BIT ADDRESSES 
32-, 64-, 128-, OR 256-BIT DATA 
READ AND WRITE 


WORD AND PARTIAL-WORD TRANSFERS 
UNLOCKED AND LOCKED TRANSFERS 


CACHE COMMAND SET 


CACHE-SHARING TRANSFER 
CACHE-MODIFYING TRANSFER 
CACHE-COPYBACK TRANSFER 
CACHE INVALIDATE 


CACHE-SHARING RESPONSE 
CACHE-MODIFYING RESPONSE 


SPLIT-TRANSACTION COMMANDS 


SPLIT-TRANSACTION RESPONSE 
REMOTE TRANSFER WITHOUT 
RESPONSE 


PACKET-SIZE SELECTION 
ATOMIC PRIMITIVE OPERATIONS 


xi 


the release of one of the data acknowledge lines. Informa- 
tion passes from the slave(s) to the master between that 
release and the next data-strobe transition. The transfer 
speed is controlled by all the participating parties, and it’s 
limited by the round-trip handshake time—40 ns to 50 ns. 


In the packet mode, the data handshake surrounds the 
transfer of an entire packet of data, and multiple packets 
can be transferred in a single transaction (Figure 3). Each 
packet is transferred at a selected rate, synchronized to the 
source of the data. The transmit clock is embedded within 
the data on a bit-by-bit basis. Every packet consists of a 
sync bit, 8, 16, 32, or 64 NRZ data bits, and a parity bit that 
returns the data line to its original state. Because every bit is 
transmitted independently, there is no clock-skew timing 
penalty. The maximum transfer rate is probably limited by 
backplane physics at around 100 Mbit/s. 


TABLE II. Status and Capability Lines 


STATUS LINES 


WAIT/END OF DATA - 
ERROR 
INTERVENTION 
CACHE SHARING 
BROADCAST 
SELECTED 

BUSY 

SYSTEM ERROR 


CAPABILITY 


SPLIT-RESPONSE TRANSFER 
COMPELLED OR PACKET TRANSFER 
PACKET TRANSMIT SPEED 
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Futurebus+ Overview 


Data Transfer (Continued) 


CONNECTION DATA TRANSFER _.. DISCONNECTION 
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AS* = ADDRESS STROBE ; M = MASTER 
AK* = ADDRESS ACKNOWLEDGE — = SLAVE 
Al* = ADDRESS ACKNOWLEDGE INVERSE 

CM* = COMMAND 

ST* = STATUS 

AD* = ADDRESS/DATA 

DS* = DATASTROBE 

DK* = DATAACKNOWLEDGE . 

DI* = DATAACKNOWLEDGE INVERSE 


FIGURE 2. Following the connection, or address phase, of this Futurebus+ transaction, the master transfers two 
words to the selected slave, then releases the bus, possibly broadcasting additional Information during disconnection. 


MASTER 
Ds* 


bl* 


SOURCE 


AD * 


AD,* 


FIRST BIT IS SYNCHRONIZATION BIT; LAST BIT IS PARITY BIT 
TL/F/11131-3 


FIGURE 3. Packet-mode transfers allow a block of data to be transmitted at a predetermined source-synchronous 
clock rate. Since the clock is embedded in each data bit, most traditional sources of skew are eliminated. 
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Cache Coherence 


The Futurebus+ cache protocols allow this specialized 
memory to perform its three main functions automatically 
and completely transparent to the software. The first func- 
tion is to convert a microprocessor's semirandom reads and 
writes into efficient burst transfers on the bus. The second is 
to provide the microprocessor with a fast local window into 
the system memory space. The third is to provide the basis 
for a multiprocessing architecture. 


The original Futurebus cache task group developed the five- 
state MOESI cache-coherence model, the acronym coming 
from the five states—Modified, Owned, Exclusive, Shared 
and Invalid. MOESI was a superset of all previously known 
. cache-coherence solutions, thereby allowing any combina- 
tion of coherence protocols to coexist in the same back- 
plane. : 

However, as the understanding of cache protocols im- 
proved, it became apparent that the complexity required to 


support the five-state MOES! model was not justified by the ‘ 


return in performance. So for Futurebus +, the group select- 
ed a four-state MESI copy-back protocol that can be gener- 
alized for caching over a hierarchy of buses using split 
transactions. Memory- and cache-agent pairs act as repeat- 
ers between processors on multiple buses accessing a sin- 
gle memory source. va 


COPY - BACK OR 
INTERVENTION 


In this cache-coherence protocol (Figure 4), every proces- 
sor-cache line has associated with it one of four states: in- 
valid (I); shared unmodified (SU); exclusive unmodified (EU); 
and exclusive modified (EM). In order for a pocessor to read 
data out of its cache, the data must first be valid—in the SU, 
EU, or EM state. If the data is invalid—in the | state—the 
cache must read the correct data from the bus. For a proc- 
essor to write data, the cache must first ensure that no other 
cache has a copy of it; in other words, the cache must ob- 
tain an exclusive copy of the data—the EU or EM states. 
Once the processor has modified data in the cache—so that 


it is in the EM state—the cache must intervene or copy back. 


to provide the system with the correct data. | 


A cache must modify its state information, or tags, in re- 
sponse to internal-processor and external-bus accesses, 
according to a set of rules described in the P896 standard. 
(Bus repeaters have a slightly different set of responsibili- 
ties, also described). An action by one cache affects every 
other cache in such a way that a consistent view of shared 
data is maintained. Futurebus+ provides the transaction 
set necessary to implement this shared-memory system ef- 


’ ficiently. 


WRITE MISS 


EM = EXCLUSIVE MODIFIED 


EU = EXCLUSIVE UNMODIFIED 
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SU = SHARED UNMODIFIED 
! = INVALID 


FIGURE 4. In the four-state cache-coherence model, a processor has private read permission 
if data Is In the EM, EU, or SU states; it has private write permission in the EM and EU states; 
and it has responsibility to intervene In the EM state. 
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Data Sheet Identification . Product Status Definition 


Formative or - This data sheet contains the design specifications for product 
‘In Design development. Specifications may change in any manner without notice. 


First This data sheet contains preliminary data, and supplementary data will 
Production be published at a later date. National Semiconductor Corporation 
reserves the right to make changes at any time without.notice in order 
to improve design and supply the best possible product. 


Full , This data sheet contains final specifications. National Semiconductor 
Production Corporation reserves the right to make changes at any time without 
notice in order to improve design and supply the best possible product. 


National Semiconductor Corporation reserves the right to make changes without further notice to any products herein to 
improve reliability, function or design. National does not assume any liability arising out of the application or use of any product 
or circuit described herein; neither does it convey any license under its patent rights, nor the rights of others. 
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PRELIMINARY 


Futurebus+ Arbitration Controller 


General Description 


The Futurebus+. Arbitration Controller is a member of the 
chipset that National Semiconductor has designed for the 
IEEE P896.1 Futurebus+ standard. The DS3875 imple- 
ments in a single chip the Arbitration function set specified 
by Acquisition, Allocation & Alignment protocol. This Con- 
troller interfaces with Futurebus+ through the NSC de- 
signed Futurebus+ Arbitration Transceiver and Handshake 
Transceiver. NSC’s Futurebus+ Arbitration Transceiver im- 
plements the arbitration circuit. The Handshake Transceiver 
can be used to transceive the Arbitration Sequencing and 
Arbitration Condition signal lines. Also in the chipset to sup- 


port the parallel protocol, two other Handshake Transceiv- ~ 


ers transceive the Address Synchronization and Data Syn- 
chronization lines. The BTL 9-bit Data Transceivers or the 
Latched Data Transceivers transceive the Address/Data, 
Data, Bus Parity, Command, Command Parity and Status 
signal lines. 


Features 

m™ The controller implements the complete requirements 
of the IEEE P896.1 specification 

m Supports Arbitration message sending and receiving 

m Supports the two modes of operation (RESTRICTED/ 
UNRESTRICTED) 

@ Software configurable double/single pass operation, 
slow/fast, JBA/Parking and _ restricted/unrestricted 
modes of arbitration 

m Built-in 1 ys timer for use in the. arbitration cycle 

BUR sdrebealll 

m User programmable 16 arbitration delays (8 slow and 
8 fast) 

@ Built-in PLL for accurate delays. The PLL accepts 
clocks from 2M MHz. to 40 MHz in steps of 1 MHz 


m Signal to unlock slave modules on transfer of tenure. 
Auto unlock through a dummy cycle if the current mas- 
ter locked resources 
Programmable delay for releasing ar* after issuing 
COMPETE/IBA_.CMPT. This is to ensure the assertion 
of the arbitration number during competition, before the 
release of ar*. Also this delay ensures there is suffi- 
cient time to assert the AD/DATA lines during Idle Bus 
Arbitration before the release of ar* 

Read/Write facility with data acknowledge for the host 
to load arbitration numbers, an arbitration message, 
and control registers 

On chip parity generator. unloads the host of the addi- 
tional parity generation function 

Separate interrupts to indicate error occurrence and ar- 
bitration message received. Interrupts cleared on a reg- 
ister write. Error status is available in a Separate status 
register 

A special output pin to dicate that a POWERFAIL 
message was received 


tion message 

FIFO strobe provided to store more than one arbitration 
message externally to prevent overrun — 

Idle Bus Arbitration (IBA) supported 

Parking implemented 

Bus initialization, system reset and Live-insertion sup- 
ported. (The logic to detect. these conditions must be 
implemented externally.) 

Testability in the form of reading from key registers 
which include the STATE, MCW, 1 us timer and pro- 
grammable input clock divider _ 


! 


National Semiconductor Futurebus+ Transcelvers and Arbitration Controller 


053885 


0S3883 
FUTUREBUS+ BTL 9=BIT DATA TRANSCEIVER 


OR DS3886 
BTL LATCHING TRANSCEIVER 


STATUS 


FUTUREBUS* BACKPLANE 


DATA SYNC = ADDRESS SYNC 
& STATUS 


32/64/128/256=BIT DATA PATH 


DS3883 
BTL 9=BIT DATA TRANSCEIVER 


$3883 sa 
BTL 9-BIT DATA TRANSCEIVER 
886 


OR OS3886 OR DS3. 
BTL LATCHING TRANSCEIVER BTL LATCHING TRANSCEIVER 


ADDRESS/DATA PATH 
& CAPABILITY 
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Pin Definition , 
’ Pin Description 

SIGNAL TO/FROM THE HANDSHAKE TRANSCEIVER 

APO Arbitration handshake signal from the controller. 
AQO Arbitration handshake signal from the controller. 
ARO Arbitration handshake signal from the controller. 
ACOO - Arbitration condition signal from the controller. 
AC1O Arbitration condition signal from the controller. 


API Arbitration handshake signal from Futurebus+. This signal is the filtered and inverted 
version of the Futurebus+ backplane signal AP*. 


AQI Arbitration handshake signal from Futurebus+ . This signal is the filtered and inverted 
version of the Futurebus+ backplane signal AQ’. 


ARI Arbitration handshake signal from Futurebus-+ . This signal is the filtered and inverted 
version of the Futurebus+ backplane signal AR*. i 


ACOI ake Arbitration condition signal from Futurebus+. 
ACI Ve Ae a ee Arbitration condition signal from Futurebus + . 


AS_CANCEL Indicates the start of the disconnection phase of the current master or cancel the current 
arbitration cycle. 


SIGNAL TO/FROM THE ARBITRATION TRANSCEIVER (Note: These pins are mapped to/from the DS3885 Futurebus + 
Arbitration Transceiver.) 


CN(7:0) Te | wol The bus to carry competition number to/from the arbitration transceiver. 
CNp fen ey le Parity bit of the competition number. 

CMPT* Enables the Arbitration number onto Futurebus+. 

AB_.RD* Direction control for the competition number bus to/from the transceiver. 


CN_LE* Latch enable for latching the Arbitration number from the controller into the transceiver. 


PER* PARITY ERROR: Indicates that a parity error was detected on the winner’s arbitration 
number. 


WIN*__GT* [estes Is Ty Win signal when competing/greater than signal when not competing (used to preempt). 

ALL1* a ae ee Indicates that all the arbitration number lines on the bus are asserted (used for messages). 

SIGNALS TO/FROM THE PARALLEL PROTOCOL CONTROLLER | 

UNLK* UNLOCK: Transfer of tenure indication to the parallel protocol controller for unlocking its 
resources. Generated only if the LKD* signal is asserted. 

ENDT* 1 END OF TENURE: Indicates the true end of bus tenure of the current master. This line may 
be asserted only after all the parallel protocol lines are released. 


LKD* LOCKED: Signal to indicate that resources have been locked in the current tenure and 
hence generate either a dummy cycle if current master or UNLK®* otherwise. 





Pin Definition (Continued) 


Pin Description 


SIGNALS TO/FROM THE PARALLEL PROTOCOL CONTROLLER (Continued) 


Signal to indicate that the Parallel Protocol controller may assert its bit on the ADDRESS/ : 
DATA bus if it is participating in an Idle Bus Arbitration. 


SZ8€Sq 


This signal indicates that IBA was successful. If this module was a competitor in the IBA 


competition (IBRQ*), then this module is the winner and now the bus master. If this module 
was the master, but did not compete in the IBA competition and IBA was successful, then the 
M bit (Status register) is negated. 





SIGNALS TO/FROM THE HOST ; 

DATA(7:0) | 8 | vo | Data bus for the host to access the register bank of the controller. 
ADD(3:0) ears Address bits for the register bank of the controller. 

cs* ars CHIP SELECT: The host can read or write to/from the controller. ' 
R_W* i Read/write signal from the host. 

DSACK* | 0 | Data acknowledge pin for host read/write. 


SEL SELECT: Determines how the controller latches in data. A “1” on the pin uses the oan edge 


of CS*. A 0” on the pin uses the falling edge of DSACK*. 
BRQ* BUS REQUEST: Indicates to the controller to acquire the bus for the module’s use. 


BGRNT* BUS GRANT: Signal asserted by the controller after the detection of a bus request. The | 


module can start using the bus. 

| 1 | MESSAGE REQUEST: Indicates to the controller to send an arbitration message. 

MESSAGE TRANSMIT: Indicates the successful transmission of an arbitration message. 
ERROR INTERRUPT: Indicates that an error occurred during the arbitration cycle. 
MESSAGE INTERRUPT: Indicates the reception of an arbitration message. 

POWER FAIL INTERRUPT: Indicates that a powerfail message was received. 

FIFO STROBE: Signal generated to load an external FIFO for received arbitration messages. 


MGRQ* 
MGTX* 
ERINT* 
MGINT* 
PFINT* 
FSTR* 
HALT* 
RINT* 


Will halt the arbitration controller in phase 0. This signal is for use during live insertion. 


Will put the arbitration controller in phase 0 and release all the bus lines except AR*. A 
selective reset is performed. The rising edge will release controller from phase 0. This r reset is 
to be used for bus initialization. sy 


Reset signal from the host. An internal reset is performed. All bus signals are falbenee The 
rising edge will put the controller in phase 0 (same as power-up reset). 


Clock input to the internal PLL. 


Poe! 
rca BL 

a ie 
aC 
aye 
ec 
ee AC 
ee 
ie 
rer 
aa 


External capacitor input for PLL—0.1 pF. 
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_ 1.0 Introduction to Futurebus + 


Futurebus+ is a high-performance asynchronous multi- 


-- plexed address/data backplane bus designed by the IEEE 


896.1 committee for use in a wide variety of multiprocessor 


architectures. The Futurebus+ standard is a next genera- 
tion backplane bus standard developed to a set of require- 
ments including openness, performance,.and system facili- 


ties and flexibilities so as not to hinder systems using this -- 


bus ‘for many generations of computer systems. Future- 
bus+ is.a single cache coherent backplane architecture 
featuring scalability, technology independent protocols, and 


explicit provisions to extend to future applications. Require- 


. ments set for the Futurebus+ architecture by the IEEE 
896.1 Futurebus+ Working Group include: 


1. Architecture, processor, and technology independent 
2. A basic asynchronous (compelled) transfer protocol 
3. An optional extended source-synchronized protocol 
4. No technology-based upper limit to bus performance 
5. Fully distributed parallel and arbitration protocols 
6. Support for fault-tolerant and high-availability systems 
7. Support for cache-based shared memory 
8. Compatible message transport definition. 


Compatibility of varying speed and technology boards con- | 


nected to the same Futurebus+ backplane is dependent 
upon broadcast capability, or a snooping cache coherence 
scheme. The performance of a Futurebus+ backplane is 
‘scalable over time to allow a low-end 32-bit system operat- 


ing at 100 Mbytes/sec to be expanded to a 256-bit system ~ 
operating at 3.2 Gbytes/sec in the future. This performance | 


is attainable by the use of source-synchronized protocols 
which eliminate spatial skews and receivers which are trig- 


gered by the incident wave from the driver. The synchroni- 
zation protocol of the Futurebus+ -backplane allows the 
synchronization domain of the sender to extend along the 
backplane, presenting only one synchronization interface 
between the bus and the receiver. 


The Futurebus+ backplane uses “Backplane Transceiver 
Logic” (BTL). BTL is a signaling standard that has been 
developed to enhance the performance of backplane bus- 
es. This standard eliminates the settling time delays, that 


severely limit the TTL bus performance, to provide signifi- | 


cantly higher bus transfer rates. BTL compatible transceiv- 
ers feature low output capacitance drivers to minimize bus 
loading, a 1V nominal! signal swing for reduced power con- 
sumption, and receivers with precision thresholds for maxi- 
mum noise immunity. For example, all Futurebus+ signals 
are open collector with termination resistors (selected to 
match the bus impedance) connected to 2V at both ends. 
The low voltage is typically 1V. All Futurebus+ signals are 
active low, indicated by an * after the signal name. (Refer to 
Table |.) Further, signals can be driven simultaneously by 
several modules. This requires that glitch filtering will be 
needed for those times to filter out the transmission line 
effect called the wire-or glitch. Refer to the Futurebus+ 
specifications for details. 


Signal Type, - {Logie | o..| mare | 
Example Signal Terminology TTL | BTL |. 


TABLE I. Signal Definitions 


Active High Asserted BV 
Signal_Name 

’ Active Low - ov} 1V 
Sional_Name” |. Negated | Logico| sv | — | 


Released fa 
" {| (Open Collector) tosico] — | av | 


2.0 Introduction to Futurebus+ 


Arbitration 


. Futurebus+ uses an evolved version of the Parallel Con- 


tention Arbiter (see Figure 4). Through the application of a 
unique arbitration vector to. this logic, only one contender ... 
will be uniquely selected as the winner. This implementation 
requires no central:‘logic on the backplane and gains the 
following advantages: 


1. The current master can see any requests and their priori- 
ty to determine whether it should give up the bus. 


2. Multiple priority levels can be implemented to allow sys- . 
tems to allocate bus bandwidth to modules running the 
most critical tasks. a 

. A Round Robin (fairness) protocol is. implemented within’ 
each priority level to ensure fair and equitable allocation 
of bus tenure to all modules. 


“4. A master elect can be preempted by a higher-priority con- 


tender. This allows the higher priority contender to ac- 
cess the bus with minimum latency (with some sacrifice 
to the system performance). 


. Arbitration Messages or events can be broadcast on the 
arbitration bus without disturbing the current transaction 
on the parallel bus. Important system control functions 
and interrupts can be sent using this mechanism without 
the need of dedicated bus lines. ar 

. A Module may support either Idle Bus Arbitration or Park- 
ing. Idle Bus Arbitration can be enabled by the current 
master to decrease the arbitration latency when ony one. ° 


competitor is requesting the bus. If Idle Bus Arbitration is ~ 


not selected then Parking may be enabled by the master. ~ 
Parking allows the current master to regain bus tenure 
(during Phase 0) to perform new bus transactions. 





2.0 Introduction to Futurebus + 
Arbitration (Continued) 


2.1 THE ARBITRATION STATES 


Figure 7 is an Arbitration State Diagram showing four states 
that a module may enter as well as the events that cause 
the module to change states during the arbitration process. 
Transitions from one state to another occur only when cer- 
tain conditions are met, based on the arbitration phase and 
the arbitration bus lines. Once a control acquisition cycle 
has started, all modules must participate in the arbitration to 
remain synchronized within the system. 


BYSTANDER 


ARBITRATION 
REQUEST 


COMPETITOR 


TRANSFER OF TENURE 


TRANSFER OF TENURE 
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3.0 Introduction to DS3875 


Arbitration Controller 


The DS3875 Arbitration Controller implements the complete 
requirements fo the IEEE 896.1 specifications. For example, 
both arbitration modes of operation (Unrestricted and Re- 
stricted) are supported. Also, either Idle Bus Arbitration or 
Parking may be selected for cases when only one request 
or no request for bus competition exist. The controller is 
software configurable to operate as a slow/fast module. 
This selects the minimum time the arbitration controller 
must wait during the arbitration competition before it can 
read the resulting competition status. This delay allows arbi- 
tration competition lines (AB[7 ... 0]*, ABP*) to settle due 


to several arbitration numbers being applied to them (Wire- 
ored bus lines). Further, a built-in PLL, which accepts a 
clock signal from 2 MHz to 40 MHz, in steps of 1 MHz, 
controls several programmable delay lines used for releas- 
ing ar* after issuing CMPT*/IBA_CMPT* (PS(1:0)). This 
delay compensates for the chip to chip skew to ensure suffi- 


_cient time to drive the arbitration competition number onto 


the arbitration competition lines during normal arbitration; or 
to assert the AD/DATA lines during Idle Bus Arbitration be- 
fore releasing ar*. Internally, the PLL also generates the 1 
ps timer used during arbitration phase 2 and phase 4. 


The Arbitration Controller supports Arbitration message 
sending. A FIFO strobe, FSTR*, is provided to store more 
than one arbitration message externally to prevent overrun. 
Also a hardwired register contains the first word of the arbi- 
tration message (h’1ff). Additional registers which hold arbi- 
tration numbers, status information, controller configuration 
information, and an arbitration message can be accessed 
by the host through Read/Write operations. For outgoing 
arbitration numbers, the on chip parity generator unloads 
the host of the parity generation function. For incoming arbi- 
tration numbers, the DS3885 Arbitration Transceiver per- 
forms the parity check function and drives the PER* input 
signal to the Controller. Separate interrupt pins for error oc- 
currence, reception of an arbitration message, and recep- 
tion of Powerfail message are available. These interrupts 
are cleared by performing a dummy write cycle to these 
registers. 


4.0 DS3875 Interfaces 


The Arbitration Controller interfaces with the DS3884 Hand- 
shake Transceiver, DS3885 Arbitration Transceiver, host 
with other support chips, Protocol Controller, and Reset and 
Initialization logic. _ 

Figure 2 depicts an internal block diagram of the DS3875 
Arbitration Controller. Figure 3 shows the interface between 
the DS3875 Arbitration Controller and the other logic on the 
module. 


The DS3884 Handshake Transceiver drives the arbitration 
handshake and condition signals to the arbitration controller 
(API, AQI, ARI, ACO!, AC1I). The Arbitration Controller con- 
tinuously monitors the Futurebus+ backplane through 
these signals. Whether the Arbitration Controller is compet- 
ing in the current contro! acquisition cycle or not, it drives 
the arbitration handshake and condition signals (APO, AQO, 
ARO, ACOO, AC10) which the handshake transceiver 
drives onto the Futurebus+ backplane. 
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4.0 DS3875 Interfaces (continued) 
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4.0 DS3875 Interfaces (Continued) 
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FIGURE 3 


When competing the DS3885 Arbitration Transceiver is en- 
abled to place the competition numbers CN(7 ... 0) and its 
associated parity bit, CNp, onto the Futurebus+ backplane. 
During every cycle, whether or not competing, the winning 
module’s arbitration number is read, the value of 
WIN*__GT* signal and PER* signal is determined and up- 
dated in the appropriate internal registers. 


The host can read or write (R/W) into the Arbitration Con- 
_ troller registers to change the controller configuration, 
check status, or R/W a new arbitration number/message. 
The host can select to latch data either on the falling edge 
of DSACK* or on the rising edge of CS* by releasing or 
asserting the SEL pin. 

The Module may become bus master during Phase 5 if the 
normal arbitration cycle was successful, Phase 0 if Parking 
was successful, or Phase 2 if IBA was successful. Upon 
becoming bus master, the Arbitration Controller will issue 
BGRNT*. This signal indicates to the Protocol Controller 


that it can now perform the desired transactions on the Par- 
allel address/data bus. 


The Protocol Controller will let the Arbitration Controller 
know if it has locked resources by asserting the LKD* sig- 
nal. If resources were locked, then at transfer of tenure, the 
Arbitration Controller will issue UNLK* to the Protocol Con- 
troller to unlock resources. 


A dummy cycle will be initiated by the Arbitration Controller 
to perform the unlocking function if lock (LKD*) is still as- 
serted after end of tenure (ENDT*) is asserted and no other 
modules are competing. Unlock will be asserted at the 
transfer of bus tenure (even if this module wins the competi- 
tion). If another module initiates arbitration competition this 
module will participate in the competition and will issue the 
unlock (UNLK*) signal upon transfer of bus tenure. When 
the bus transaction is complete and no resources are 
locked, the Protocol Controller has the option of enabling 
either Idle Bus Arbitration or parking (IBA_.PK* in CTRL9). 
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4.0 DS3875 Interfaces (Continued) 


The input signal ALL1* (AB{[7 .. . 0]* and ABp* all asserted) 
is used to determine if any module is sending an arbitration 
message during pass 1. For convenience, the Arbitration 
Controller outputs FSTR* (to an external FIFO) during mes- 
sage reception so more than one arbitration message may 
be stored by the module. 


The Arbitration Controller has dedicated interrupt pins. . 


(ERINT*, MGINT*, PFINT*) that interface with the Protocol 
Controller so that important messages and error indications 
can be quickly detected. 


The Protocol Controller will issue 3 the message request or 
bus request signals to the DS3875. When a message has 
been transmitted (Second Pass of arbitration, Phase 5), the 
Arbitration Controller will assert MGTX*. 


On board reset, initialization, power-up, and live insertion 
logic will inform the Arbitration Controller which type of reset 
operation to perform: Power-Up Reset (RST*), Initialization 
(RINT*), or live insertion (HALT*). See Sections 10.0 and 
11.0 for more information. 


5.0 Arbitrating for Futurebus + 


The arbitration process allows a module to seek and gain 
tenure of Futurebus+ to transfer data to or from another 
module. The arbitration process is independent of the data 
transfer process and may take place concurrently with data 
transactions on Futurebus+. If a module (or several mod- 


ules) want to use the bus, an arbitration competition takes _ 


place. The module with the highest arbitration number ar gets 
tenure of the bus. 


The National Semiconductor solution to Futurebus+ ‘arbi- 
tration includes the DS3875_ Arbitration Controller, the 


DS3885 Arbitration Transceiver and the DS3884 Hand- 
shake Transceiver (see front page system block diagram). 
More information on Arbitration as it applies to the Future- 
bus+ IEEE standard is available in Section 5 of the 
“Futurebus+ P896.1 Logical Layer Specification”. 


5.1 UNRESTRICTED/ RESTRICTED MODES OF 
OPERATION ~- 


The Arbitration Controller supports either the Unrestricted 
or the Restricted mode of arbitration. In the system environ- 
ment, all ‘modules must be configured to porate in the 
same mode at any given time. 


During initialization, the Unrestricted mode is set since it 
must be supported by all modules. The Unrestricted mode 
allows a single pass of an 8-bit arbitration number or a two 
pass of a 16-bit arbitration number to be used. © 


Futurebus+ allows arbitration numbers requiring a single 
pass control acquisition cycle to be mixed with those requir- 


ing a two pass control acquisition cycle. During the first pass 
of a two pass cycle, more than one module may have the 


same number; however, during the second pass only one 


winner results where the competition numbers must be 
unique. A logic zero in the RU__ bit of the CTRL2 register 
selects the unrestricted mode. 


The Restricted mode of operation is optional and is selected 
by setting the RU__ bit to a logic one in the CTRL2 register. 
This mode limits arbitration numbers to 8 bits. Thus, only a 
single control acquisition cycle occurs where all numbers 
are unique. The arbitration numbers are assigned by the 
module and can be dynamically changed. 


5.2 THE ARBITRATION NUMBER AND ARBITRATION 


CIRCUIT 


Each module has a unique arbitration number. When two or 
more modules compete for the bus, the module with the 
highest arbitration number will win the competition. 


The DS3885 Arbitration Transceiver contains the arbitration 
circuit. See Figure 4 for a functional model of the arbitration 
circuit. A Parallel Contention Arbitration Protoco! controls 
how modules assert and release the AB[7 ... 0]* and 
ABp*. After a period of time (ta) the protocol ensures that 
only the winners arbitration number will remain on the 
ABI7 ... 0]* and ABp*. 


The arbitration number consists of one or two competition 
numbers, CN(7 ... 0). The Arbitration Controller Transmits/ 
Receives the competition number to/from the Arbitration 
Transceiver. The CN__LE* signal latches the competition 
number into the transceiver while the AB_RD* signal al- 
lows the controller to read in the winner's competition num- 
ber. Along with the competition number, the Arbitration Con- 
troller transmits the CNp bit, the generated parity bit of the 
competition number, to the Arbitration Transceiver. Odd 
parity, as specified in the Futurebus+ specifications, is im- 
plemented. Thus, CNp is set when even number of ones are 
present in the competition number. When CN(7 ... 0) is 
received from the Arbitration Transceiver, the PER* bit is 
checked for error detection. 


Referring to Table II, in the Unrestricted mode, the CN7 bit 
indicates if the module requires another arbitration pass. 
When a one pass and a two pass arbitration number occur 
in the same control acquisition cycle, the one pass arbitra- 
tion number will win. 


The DS3875 allows the module to dynamically change the 
arbitration number by writing into the TXCNO and/or the 
TXCN1 registers (see Section 7). If the arbitration number is 
changed during an arbitration cycle it will be used in the next 
arbitration competition. 


The arbitration number is composed of three fields: Priority 
Field, Round Robin Field, and a Unique Field. 
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5.0 Arbitrating for Futurebus + (Continued). - 


while also in such a way that minimizes the arbitration set- 


5.2.1 Priority Field (PR) ; 
The priority field represents a module's priority class which 
is determined by the system designer. In the unrestricted 
mode, the length of this field is a maximum of eight. bits 
while in the restricted mode it is two bits. 


§.2.2 Round Robin Field (RR) 


This field is represented by a single bit, CN5, in both modes 
of operation. The round robin protocol ensures that all mod- 
ules in the same priority class have fair and equal access of 
the bus. A module is allowed to get tenure of the bus in a 
sequence defined by its value in the unique field. 

The round robin bit is adjusted by the Arbitration Controller 
each time a transfer of tenure occurs in the module’s same 
priority class whether or not the module is competing in the 


control acquisition cycle. In the module’s same priority ~ 


class, the round robin bit is set when tenure of the bus is 
transferred to a module with a larger unique field value or 
the round robin bit is cleared when tenure of the bus is 
transferred to a module with a lesser unique field value. : 


In the event, where the module’s ‘arbitration number is 


changed, after the next control acquisition cycle, the round - 


robin bit is adjusted accordingly. 


5.2.3 Unique Field (U) 


The five bit unique field, CN(4...0), guarantees the unique- 
ness of the module's arbitration number. The unique num- 
ber may correspond to the module’s geographical address 
or may be allocated by the system designer as he chooses 


tling time. The value 11111” is not allowed in systems us- 
ing arbitration messages. 

5.3 ARBITRATION CATEGORIES 

A module can be in one of six categories when a control 
acquisition cycle is in progress; 

Competitor for the Parallel bus 

® Competitor to send a message 

¢ By-Stander 


" @ By-Stander who decides to invoke Pre-emption 


e Master 
e Master Elect 


5.3.1 Competitor for the Parallel Bus 
A Module may become a competitor for the parallel bus if it 


- issues a Bus Request (! BRQ*) to the arbitration controller 


before the arbitration cycle Phase 1 starts, see Figure 5a. 


If the module issues a bus request and the arbitration cycle 
is in phase 0, the controller will assert APO to start an arbi- 


~~ tration competition. If an arbitration competition has already 


started, and the module’s bus request comes prior to API 
being asserted on the arbitration bus, the module may enter 
this arbitration cycle. If an arbitration competition has al- 
ready started, and the module’s bus request comes after 
AP* being asserted on the arbitration bus, the module will 
have to wait until the next arbitration cycle to compete (or 
pre-empt the current arbitration cycle in Phase 3). 


TABLE II. Arbitration Number : 
| pit =| ~on7_| one, | ons | ona | cna | on2 | ont | ono | 
Unrestricted Mode—Single Pass 


[rast [+ [pro ] pn |. uw | uw [ w | uw | w | 
| Past | 0 {| pr7_| pre. | prs | pra | prs | pre | prt 
| Pasoz | 1 | pro | oR | ous] us| te | | 


[recot [per [pmo [mm [| w | w [we [ww lw 
See ee ee ey ee wn 
[rose [a | «| os | « |» | «# |» | «| 





5.0 Arbitrating for Futurebus + (continueg) 


5.3.2 Competitor to Send a Message 
The Arbitration Controller supports message sending. Mes- 


sage sending is implemented in the unrestricted mode in a’ 


two pass arbitration cycle. The first pass of all ones (1FF H) 
in the competition number identifies the transaction as a 


message. The ALL1* input signal is asserted by the Arbitra- . 


tion Transceiver when it detects .1FF H on the ABI7 ... 0]* 
and ABp* lines. The arbitration controller. has a hardwired 
register that holds the first pass word. Further, a dedicated 
pin MGRQ* (message request) places the Arbitration Con- 
troller in the message sending mode. 


The message that is to be transmitted is loaded into thie 
TXMSG register. The message of 1FF H is reserved as the 
powerfail message. Other messages are to be coded by the 
system designer with the greater priority messages having a 
higher arbitration number. Obviously, if more than one mod- 


ule simultaneously desires to send a message, the message | 


with the highest arbitration number will be transmitted. 


When a message is sent, no transfer of tenure takes place. _ 


Thus, the master (M) or the round robin (RR) bits are not 
updated. Upon successfully transmitting the message, 
MGTX** signal is asserted. 

When a message is received by the Arbitration Controller 
(Phase 5), message interrupt . (MGINT*) is asserted and 


FIFO Strobe (FSTR*) is negated. In the case of a Powerfail - 


message being received; the PFINT* signal is asserted. 
When the PFINT* signal is asserted, the MGINT* and 
FSTR®* signals are not generated. See Fi igure 5d. 

When sending a message, once the MGRQ* signal is as- 
serted, until the message has been transmitted, all other 
requests are blocked. Upon the MGTX* signal being re- 


leased, the message request signal will be reevaluated to 
see if another message needs to be sent. 


If this module is the module sending the arbitration mes- 

sage, then the message interrupt (MGINT*) or the Powerfail 
interrupt (PFINT*) will not be generated on this module. 
These interrupts are generated only upon the reception of a 
message from another module. Refer to Figure 5e. 


5.3.2.1 Using an External FIFO to Store Messages 


The Arbitration Controller provides a FIFO strobe (FSTR*) 
signal to store more than one arbitration message in an 
external FIFO. A rising edge on FSTR* is generated upon 
the reception of an arbitration message. 

See Figure 3 and.Timing Diagrams: T6, Phase 2 and Phase 
5. 


1. FSTR* is always asserted (! FSTR*) during phase 2. 


2. FSTR* is negated (FSTR*) during phase 5 given the fol- 
lowing conditions... 
1. The message is not being sent by this nodule: 

2. This is the second pass of an arbitration message. 

3. No errors occurred during this arbitration cycle. 

4. This is not a powerfail interrupt message (! PFINT*). 
The external latch shown in Figure 3 is enabled by AB. 
RD* to temporarily hold the message. While AB_RD* is 
low (see timing diagrams phase 2 and 5), the latch is fall 
through. -Then, during phase 5 on the rising edge of FSTR"*, 
the message held in the latch will be strobed into the FIFO. 


5.3.3 By-Stander 


A Module is considered a by-stander i in the arbitration com- 


petition if it does not issue a Bus Request (! BRQ*) to the 
arbitration controller before arbitration cycle Phase 1 starts. 


5.3.4 By-Stander Who Decides to Invoke Pre-emption 


_A module with, a higher arbitration number than the master 


elect may initiate a new arbitration cycle to establish a new 


_ master. This process, referred to as pre-emption, allows a 


high priority to acquire tenure of the bus with minimum laten- 
Cy. 

Pre- -emption is allowed in phase 3 when all of the following 
conditions are met: 


1. the arbitration number is greater than the arbitration 
number on the bus 


2. a bus request signal was recently received 

3. did not participate in the arbitration competition phase 2. 
The master elect may be preempted by asserting AC10. 
Pre-emption is not allowed during: 


“ @ the first pass of a two pass cycle 


® message sending 

These two events are given higher precedence. 

If a module decides to preempt and changes its competition 
number during phase.2 or phase 3 in the Arbitration Control- 
ler, the Arbitration Transceiver will still use the current 
latched competition number to make the greater than com- 
parison. When the next arbitration cycle occurs, the new 
competition number will be used. 


5.3.5 Master 


The Master is the module that currently has tenure of the 
parallel! bus. 


5.3.6 Master Elect 


_The Master Elect is the module that won the current arbitra- 


tion cycle. The Master Elect will become master upon trans- 
fer of tenure, 
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5.0 Arbitrating for Futurebus+ (Continued) 
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FIGURE 5. Bus Request Timing (Normal Arbitration, Idle Bus Arbitration and Parking) 
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e. Message Sending 
FIGURE 5. Bus Request Timing (Normal Arbitration, Idle Bus Arbitration and Parking) (Continued) 


5.4 FUTUREBUS+ OPTIONAL MEANS OF 
ARBITRATION 


Besides the normal Futurebus+ Parallel Contention Arbitra- 
tion, the Futurebus+ Specification allows two other option- 
al arbitration methods to acquire the parallel bus quickly: 


© Idle Bus Arbitration 
© Parking 


Both of these arbitration methods are supported by the Na- 
tional Semiconductor DS3875 Arbitration Controller. 


5.4.1 Idle Bus Arbitration (IBA) 


idle Bus Arbitration (IBA) is selected by setting the IBAPK* 
bit in CTRL3 register. The aim of IBA is to give a module 
quick access to Futurebus+ when the current master has 
completed its transfers. 


IBA is invoked the same as a normal arbitration bus request 
(! BRQ*) but uses the parallel bus (AS* negated, DS* as- 
serted, and the parallel address/data bus) to determine the 
winner of the arbitration cycle, see Figure 5a, b. 


During normal arbitration the transfer of Futurebus+ tenure 
occurs during phase 5. During IBA the transfer of Future- 
bus+ tenure occurs during phase 2. During IBA the AC1O 
arbitration condition signal will be asserted by the new mas- 
ter. This will cancel the transfer of tenure during the normal 
arbitration cycle. Note that Futurebus+ tenure was trans- 
ferred but only the two modules involved in the IBA (the 
master and the master elect) know that the transfer of ten- 


ure has taken place. All the other modules involved in the 
normal arbitration cycle see that the transfer of tenure dur- 
ing the normal arbitration cycle was canceled. 


lf two or more modules have a request, then normal arbitra- 
tion will determine which module will gain access. IBA takes 
place on the parallel highway, AD/DATA (31 ... 0). Each 
module is assigned a bit which is to be asserted during IBA. 
If only one bit is asserted during the IBA competition, then 
IBA issues the bus grant signal to that module. Concurrently 
with IBA, normal arbitration takes place. If a module does 
not want IBA to issue a bus grant, IBA may be inhibited by 
asserting DI*. During phase 5, normal arbitration will deter- 
mine appropriate actions. 


5.4.1.1 Masters Support Circultry to Enable IBA 


If IBA is allowed, it is invoked during phase 0. In order to 
support IBA external logic is needed in addition to the arbi- 
tration controller. The Masters external logic must monitor 
the arbitration control acquisition synchronization signals 
(AP*, AQ*, AR*) and the parallel bus address handshake 
signals (AS*, AK*, Al*). If the master supports IBA it should 
wait until it is ready to end its bus tenure (ENDT* asserted). 
Then when it releases AS* it should assert ds* to enable 
modules to participate in IBA competition. 


5.4.1.2 Modules Support Circuitry to Participate in IBA 


If a module wants to use IBA to gain tenure of Futurebus+ 
it must use external logic to monitor the arbitration control 
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5.0 Arbitrating for Futurebus + (Continued) 


acquisition synchronization signals (AP*, AQ*, AR*), the 
parallel bus address handshake signals (AS*, AK*, Al*), the 
parallel bus data sync signal (DS*) and data acknowledge 
inverse (DI*), and the IBA_CPT* output from the arbitration 
controller. 


5.4.2 Parking 


During Power Up, the Arbitration Controller is programmed 
to perform either Idle Bus Arbitration or Parking by setting or 
clearing the IBAPK* bit in the CTLR3 register. Parking is 


selected by clearing the IBAPK* bit. The aim of Parking is to © 


give the Futurebus+ bus Master quick access to the bus to 
perform other transfers when no one else desires to use it. 
Thus, it is not necessary for the master to go through the 
entire arbitration cycle to get the BGNT* signal. Parking is- 
sues BGNT* in Phase 0, see Figure 5c. \f another module 
gets a message request or bus request, the arbitration com- 
petition cycle begins like it nofmally’ does to handle the re- 
quest. 


All of the following conditions should be met to take advan- ‘ 


tage of Parking: 
1. Parking in selected 
. module must be the current Master 
. ENDT* signal is high 
. BGRNT* signal is high 
. BRQ* signal is asserted low while in phase 0 
. LKD* signal is high (Resources are not locked) 


When these conditions are true, the Arbitration Controller 
issues the BGRNT* signal (asserted low) in phase 0. Upon 


end of tenure, BGRNT* signal will be released. The Master. ~~ 
may continue to use Parking to perform transactions until . 


after the arbitration competnon cycle selects a new master 
(see Fi igures Se and 7). 


Parking is allowed only when the Master has all resources 
unlocked (indicated by LKD* signa! being high). During 
phase 0, if the master still has resources locked (ENDT* 
and BGRNT* signals are high), the Arbitration Controller will 
immediately initiate a dummy cycle to unlock resources. The 
UNLK® signal is generated during phase'5 upon the suc- 
cessful transfer of tenure. The transfer of tenure may be 
with itself or another module. 


5.5 THE ARBITRATION PHASES 


The arbitration process consists of transitioning through six 
phases (Phase 0 thru Phase 5) of the three arbitration syn- 
chronization signals (AP*, AQ*, AR*). To transition between 
control acquisition phases only one of the three arbitration 
synchronization signals will transition. 


The Arbitration process is asynchronous and occurs as fast 
as all the modules that contain arbitration logic can tran- 
sition through the arbitration phases. If a two-pass arbitra- 
tion competition has been selected the entire control acqui- 
sition cycle is repeated twice. 

Each arbitration synchronization signal (AP*, AQ*, AR*) 
represents the wire-OR of each of the individual synchroni- 
zation signals from each of the modules. For any of the 
synchronization signals on the bus to be released, all the 
modules must release their individual synchronization sig- 
nals (ap*, aq*, ar*). Therefore, the release of a synchroniza- 
tion signal forms a global synchronization point for all the 
modules. Likewise, during the assertion of a synchronization 
signal all modules must remain synchronized by asserting 
their own signals in response. 


Each module must participate in the contro! acquisition cy- 


cle, whether or not the module is competing, to remain syn- 


chronized with the other modules. Figure 6 is a timing dia- 
gram of the Control Acquisition Sequence. Figures 7a-f are 
state transition diagrams of the DS3875 Arbitration Contro!- 
ler. Tables Ill and IV represent the internal register bits that 
are affected by the arbitration states and their transitions. 


The DS3875 Arbitration Controller transitions to the next 


_arbitration phase upon (see Figure 6): 


1. APO output signal being asserted to phase 1 


2. ARI input signal being negated to phase 2. (This input is 


filtered and indicates all modules have released the AR* 
synchronization signal on the Futurebus+ backplane.) 

. AQO output signal being asserted to phase 3 

. API input signal being negated to phase 4. (This input is 
filtered and indicates all modules have released the AP* 
synchronization signal on the Futurebus+. backplane.) 

. ARO output signal being asserted to phase 5 

. AQI input signal being negated to phase 0. (This input is 
filtered and indicates al! modules have released the AQ* 
synchronization signal on the Futurebus + backplane.) 





5.0 Arbitrating for Futurebus+ (Continued) 
PHASE 0 PHASE 1 PHASE 2 PHASE 3 PHASE 4 PHASE 5 ; PHASE 0 
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DS3875 FUTUREBUS-+ Arbitration Controller Input Signals 
FIGURE 6a. Arbitration Phases 


B. Single Access, AS_.CANCEL Timing Diagram (AS Is tied directly to the 
AS_CANCEL Input of the Arbitration Controller) 
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FIGURE 6b. Timing of the AS_.CANCEL Signal 
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5.0 Arbitrating for Futurebus+ (Continued) 


C. Multiple Accesses, AS_.CANCEL Timing Diagram (AS Is latched before being input to the AS_.CANCEL 
input of the Arbitration Controller. At the end of the last transfer the latch [s reset) 


ARBITRATION PHASE 


BGRNT* 
AS . — ¥) BUS TRANSACTION #1 BUS TRANSACTION ma 


AS_CANCEL AS LATCHED 


ENDT* . 
TL/H/10747-14 


D. Multiple Accesses, AS_.CANCEL Timig Diagram (AS Is tied directly to the AS__.CANCEL Input 
of the Arbitration Controller. The Master must guarantee that the second transfer, or ENDT*, will come within 
1 ps of the falling edge of the initial transfer AS signal). 
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BGRNT* 


MASTERS AC10 


MASTERS AS , p VEE TRANSACTION bie 
MASTERS AS_CANCEL BUS TRANSACTION rs 


MASTERS ENDT* AS IN LESS THAN FT 


OR ENDT* IN LESS THEN 1 us 


. ¢ : . TL/H/10747-15 
FIGURES 6c, 6d. Timing of the AS_.CANCEL Signal 


§.5.1 Phase 0, Idle Phase 5.5.1.1 Phase 0, Normal Arbitration Events That Cause a 
This Phase is characterized by AP* released and AR* as- Transition to Phase 1 . 
serted on Futurebus+ and AQf negated on the module There are five conditions during normal arbitration where 
board. See Figure 7a for the DS3875 Arbitration Controller APO will be asserted causing a transition to Phase 1: 
Phase 0 state diagram. 1. If Two-Pass ‘Arbitration is selected, a bus request has 
The arbitration controller will be negating APO, asserting been received (| BRQ* + ! MGRQ* + Dummy Cycle) 
ARO and be receiving AQI negated. This is the state of the and this module was a winner during the first pass of 
arbitration synchronization lines when no control acquisition arbitration, then APO will be asserted. 
cycle is in progress or between the two control alae . Though this module may not be requesting Futurebus + 
cycles of a two-pass arbitration sequence. . .° ‘another module: may want to arbitrate for Futurebus+ 
While in Phase 0 the following actions are performed: and assert AP*. This action will cause the AP input (API) 
1. If ! HALT* is asserted the arbitration controller will not on this module to be asserted. API asserted will cause 
transition to Phase 1 until HALT* is negated. this modules arbitration controller to assert APO. 


2. If any of the “New Bits” are set (NCN, NGO, NDS) the . If this module is currently the master and ! LK* is assert- 
corresponding internal arbitration controller registers will ed, BGRNT® is negated, ! ENDT™ has been received, no 
be updated and then the ‘“‘New Bits” will be reset. other requests have been received and API is negated, 

eee Gad : ives : the module will initiate a dummy cycle to unlock its re- 

3. He arbitration condition lines (AC1*, ACO*) will be nega sources by asserting APO (f it is doing Single Pass or the 

i First Pass of Two-Pass Arbitration). 


ete oe ihre: types Or aloirationmey-Oceur . A message request (! MGRQ") will cause APO to be as- 

nae serted (if it is doing Single Pass or the First Pass of Two- 
1. Normal arbitration Pass Arbitration). Note that if both a bus request 
2. Idle Bus Arbitration (IBA) (! BRQ*) and ! MGRQ* are received during phase 0, 


3. Parking 
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5.0 Arbitrating for Futurebus + (Continued) 


! MGRQ* will be given a higher priority and will be acted 
upon during this arbitration cycle. ! BRQ* will wait to arbi- 
trate during the next arbitration cycle. 


. A Bus Request (! BRQ*) will cause APO to be asserted 
(if it is doing Single Pass or the First Pass of Two-Pass 
Arbitration). This will cause the Futurebus+ AP* to be 
asserted and will indicate to the other modules that an 
arbitration competition is beginning. 

Note that the user will violate the Futurebus+ specification 
if he leaves the local modules resources locked (! LKD*) 
and has IBA enabled in the arbitration controller. This inci- 
dent is dangerous because it could lead to another module 
winning IBA with the local modules resources being locked. 
If the other module tried to access the local modules re- 
sources it would result in deadlock. 


5.5.1.2 Phase 0, Idle Bus Arbitration Events That Cause 
a Transition to Phase 1 


If IBA is desired and the arbitration cycle is in Phase 0 
(! APO, ! AQI, ARO), the parallel bus is idle (AS*, AK*, ! Al*), 
and DS* has been released for a minimum period of time 
(Futurebus+ spec.) the Masters external logic may assert ! 
DS*. This will alert any module eee of doing IBA that 
IBA has been enabled. 


5.5.1.3 Phase 0, Parking 


The aim of Parking is to give the Futurebus+ bus master 
quick access to the bus to perform other transfers when no 
one else desires to use it. If Parking is enabled (! IBA__PK*) 
and is successful the arbitration controller will issue BGNT* 
in Phase 0. If another module gets a message request or 
bus request, the arbitration competition cycle begins like it 
normally does to handle the request (see Section 5.5.4 for 
more information). 


5.5.2 Phase 1, Decision Phase 


This Phase is characterized by AP* and AR* asserted and 
AQ* released on Futurebus+. See Figure 7b for the 
DS3875 Arbitration Controller Phase 1 state diagram. 


The arbitration controller will be asserting APO and ARO 
and negating AQO. This is the state of the arbitration syn- 
chronization lines when the decision phase (1) is in prog- 
ress. 


During Phase 1 the individual modules must make the deci- 
sion whether they want to compete. This decision will be 
based upon the state of the modules bus request, message 
request or locked status (! BRQ* or ! MSGRQ* or! LKD*) at 
the time APO is asserted. Since this condition is subject to 
mestastability a metastable hardened latch is used internal 
to the DS3875 to resolve this potential condition. 


If the module is going to compete the arbitration competition 
number (CN(7:0)) and its parity bit (CNp) will be asserted to 
the arbitration transceiver, Latch enable of the arbitration 
transceiver will be asserted and negated (! CN__LE* assert- 
ed for 20 ns) to latch in the arbitration number, and compete 
will be asserted (! CMPT*) to enable the arbitration competi- 
tion number onto Futurebus+. 

If the module is a slow module (! FS*, see Section 7.6) the 
arbitration handshake signal ACOO will be asserted. 

Once the decision to compete has been made, the arbitra- 
tion handshake signal (! AC10) that cancels the arbitration 
cycle will be negated. The Programmable Skew (PS(1:0)) 
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gives time for the arbitration number to become valid on 
Futurebus+ before ARO is negated. Once the Programma- 
ble Skew has timed out ARO will be negated. Once all mod- 
ules have negated AR* the arbitration cycle will transition to 
Phase 2. 


Once all modules have negated AR* alps timer is started. 
This timer is used to guarantee that phase 2 is completed 
within one to 2 ps. 


5.5.2.1 Phase 1, Idle Bus Arbitration Events That Cause 
a Transition to Phase 2 


During phase 1 the arbitration controller will output ! IBA_ 
CPT*. When the external logic sees ! IBA_.CTP* and the 
parallel bus is inactive (AS*, AK*, ! Al*) it should drive one 
of the data bits of the parallel address/data bus. 


5.5.3 Phase 2, Competition Phase 


This Phase is characterized by AP* asserted and AQ* and 

AR* released on Futurebus+. See Figure 7c for the 

DS3875 Arbitration Controller Phase 2 state diagram. 

The arbitration controller will be asserting APO, negating 

AQO and receiving ARI negated. This is the state of the 

arbitration synchronization lines when the competition 

phase (2) is in progress. 

While in Phase 2 the following actions are portend. 

1. AB__RD* is asserted after 30 ns. This allows the arbitra- 
tion controller to monitor the winning competition num- 
ber. 


2. The FIFO STRobe is now asserted (! FSTR*). 


There are two conditions that can cause AQO to be assert- 
ed causing a transition to Phase 3: 


1. The AQI input being asserted. 

2. Competing, arbitration competition settling time (ts) ex- 
pired, one to 2 pws Phase 2 arbitration error timer not 
expired, and the WIN*__GT* input being asserted. 


5.5.3.1 Phase 2, Idle Bus Arbitration Events That Cause 
a Transition to Phase 3 
The external logic should drive the IBA Success signal 
(! IBA_S*) during phase 2 if DI* is released, only this mod- 
ules data bit is driven on the data bus, and the arbitration 
settling Time (ts) has not expired. 

When the arbitration controller sees | IBA_S* asserted it 
will issue bus grant (! BGRNT*) to give access of the bus to 
the module that won the IBA. If two or more modules have a 
request, then normal arbitration will determine which mod- 
ule will gain access. 


5.5.4 Phase 3, ErrorCheck Phase 
This Phase is characterized by AP* and AQ* asserted AR* 
released on Futurebus+. See Figure 7d for the DS3875 
Arbitration Controller Phase 3 state diagram. Also see Fig- 
ures 6b, c, d for how AS__CANCEL relates to Phase 3. . 
The arbitration controller will be asserting APO and AQO, 
and negating ARO. This is the state of the arbitration syn- 
chronization lines when the error check phase (3) i is in prog- 
ress. 
ea in Phase 3 the following actions are performed: 
. If.the module.is a competitor and winner of the arbitra- 
tion, the W(winner) bit in the STATUS register is set. 


2. Upon entering phase 3, after 20 ns, AB_.RD* is negated. 
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5.0 Arbitrating for Futurebus + (continued) 


There are seven conditions that will cause the arbitration 
controller to negate APO: 


1. This module has had a Bus ReQuest (! BRQ*), won IBA, 
and asserted AC10O and AS. 


2. The current master releases AS (| AS__CANCEL). The 
master has completed its transactions on the parallel 
bus, see Figures 6b, c, d. 


. This module detected the 1 ys timeout or a parity error 
occurred during the arbitration cycle. This error condition 
will cause the assertion of ACOO and AC10 and ERINT* 
signals which will inhibit the transfer of tenure during this 
arbitration cycle. 


. Another module has detected that transfer of tenure is to 
be inhibited (AC1)). 

. This module was competing and won the competition 
where this is the first pass of a two pass arbitration cycle. 


. This module did not compete (CMPT*) but now has a 
bus request (! BRQ*) and its competition number is 
greater than (| WIN*__GT*) the modules competition 
number that won the current arbitration competition. This 
module preempts the current arbitration competition by 
asserting AC10. This inhibits the transfer of tenure dur- 
ing this arbitration cycle and allows a new arbitration cy- 
cle to be initiated in which this module can compete. 


. This module was competing (1! CMPT") and won the com- 
petition (W bit of Status register set) but the bus request 
or message request has been negated (BRQ* or 
MGRQ"). This error condition will cause the assertion of 

_ ACOO, AC1O and ERINT* signals which will inhibit the 
transfer of tenure during this arbitration cycle. 


After all the modules have negated AP*, upon receiving 
!API, the arbitration cycle will transition to Phase 4. 


5.5.4.1 Phase 3, Idle Bus Arbitration Events That Cause 
a Transition to Phase 4 


During phase 3 of the arbitration cycle, when the current 
master has not yet released the bus (AS), the new master (a 
module that was competing (!IBA_.CMPT*) and won 
(IIBA_S*)) will drive AC10O to inhibit the transfer of tenure 
during the normal bus arbitration cycle (tenure was trans- 
ferred during the IBA cycle). 


Note: The new master will now continue the normal arbitration process to 
completion but may begin conducting transactions on the bus. 


5.5.5 Phase 4, Master Release Phase 


This Phase is characterized by AP* released, AQ* asserted, 
and AR* released on Futurebus+. See Figure 7e for the 
DS3875 Arbitration Controller Phase 4 state diagram and 
Figures 6b, c, d for how AS__CANCEL relates to phase 4. 


The arbitration controller will be receiving API negated, as- 
serting AQO and negating ARO. This is the state of the 
arbitration synchronization lines when the master release 
phase (4) is in progress. 

While in Phase 4 the following actions are performed: 


1. All modules, other then the bus master, start a 1 ps tim- 
er. This is referred to as the Master release timer. The 
master has 1 us to complete its transactions or to inhibit 
the transfer of tenure and proceed to phase 5. This timer 
is specified in the Futurebus+ specification so in the 
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event where the current master does not respond, the 
- master elect may assume mastership during phase 5. 
2. The CMPT* signal is negated (CMPT*). 
There are six conditions that can cause ARO to be asserted 
causing a transition to Phase 5: 
1. Transfer of tenure is inhibited indicated by the assertion 
of AC1I. 
2. Was not Master and the ARI input was asserted. 
3. Was Master and did not cancel (! AS_.CANCEL) the ar- 
bitration competition, see Figures 6b, c, d. 
. There is no current master (immediately following power 
up) so the master elect may assert ARO. 


. Was Master and did cancel (! AS_.CANCEL) the arbitra: 
tion competition, see Figure 6d. |n this case the current 
master will assert AC10O to inhibit the transfer of tenure 
during this arbitration cycle. 


. All modules other then the current master detect the 
Master Release Timeout. 
5.5.6 Phase 5, Tenure Transfer Phase 


This Phase is characterized by AP* released, AQ* asserted, 
and AR* asserted on Futurebus+. See Figure 7f for the 
DS3875 Arbitration Controller Phase 5 state diagram. 


The arbitration controller will be negating API and asserting 
AQO and ARO. This is the state of the arbitration synchroni- 
zation lines when the tenure transfer phase (5) is in prog- 
ress. 


While in Phase 5 the following actions are performed: 


1. If IBA_CMPT* signal was asserted, it is now negated 
(IBA_.CMPT*). 

2. The unlock signal (! UNLK*) will be asserted if locked 
(| LKD*) is asserted and the arbitration condition signals 
(ACOI, AC1I) are negated. 


. This phase will update the following status bits: 

1. The Master status bit (bit 5) in the status register. 

2. The Competitor status bit (bit 4) in the status register. 
3. The WIN status bit (bit 3) in the status register. 
4 


. The Uniqueness, round robin and priority fields of the 
RXCN1 register. 


5. The Priority field of the RXCNO register. 


There are four conditions that can cause AQO to be negat- 
ed: 


1. Had a message request (! MGRQ*) and won the compe- 


tition (! WIN*__GT*). In this case the message transmit- 
ted output will also be asserted (! MSGTX”*). 


. Competed for the bus (! CMPT*), there were no errors 

(! ACOI, ! AC11), and won the competition (! WIN*__GT*). 
In this case the bus grant output will be asserted 
(! BGRNT*) and the internal master bit will be set (M, bit 


5 in the status register). . 

. There were no errors (! ACOI, ! AC1I) and the module is 
not the winner. Resets the M bit in the status register. 

. A Message was received. In this case either message 
interrupt will be asserted (! MGINT*) or the powerfail in- 
terrupt (! PFINT*) will be asserted. 





5.0 Arbitrating for Futurebus+ (continued) 

When a message is received the FIFO strobe (FSTR’*) will 2. This is the second pass of an arbitration message. 
be negated, strobing a new message into the external FIFO, 3. No errors occurred during this arbitration cycle. 
given the following conditions: 4. This is not a powerfail interrupt message (! PFINT*). 


1, Theimessage is not being sent by this module. Once all the modules have negated AQ*, upon receiving 
!AQI, the arbitration cycle wiil transition to Phase 0. 
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(SINGLE~PASS + 1ST PASS OF TWO PASS) 


PHASE 1 
‘ DECISION PHASE ~ 
APO, !:AQO, ARO 
(SEE PHASE 1 ARBITRATION 
STATE DIAGRAM) 


: . TL/H/10747-16 
FIGURE 7a. DS3875 Phase 0 Arbitration State Diagram 


Note: **HALT* is assumed to be negated in this state diagram. Also, the arbitration Controller GO bit in CTRL3 register must be asserted for the controller to 
accept requests. Otherwise this module may not compete but will be a by-stander. 


Note 1: Idle Bus Arbritation during Phase 0 is not an internal state of the Arbitration Controller. It is shown in this state diagram only to give a better understanding 
of Phase 0 arbitration. 


Note 2: The Arbitration Controller does not check for LKD®, but it should not be asserted during IBA to be in compliance with the Futurebus+ specification. If lock 
was asserted during IBA another module could win IBA and try to access this modules locked resources, this would result in deadlock. Also, the Arbitration 
controller does not check AS* & | DS* & DI*, this is left up to external logic and this must be the first pass if two pass arbitration has been selected. 


Note 3: The output ! di* from this module is driven from external control logic, it is only shown in this diagram to allow a clearer understanding of how IBA relates to 
normal arbitration. 


Note 4: Note that message request (MGRQ"*) has a higher priority inside the arbitration controller then does bus request (BRQ*). 


Note 5: This is a dummy arbitration cycle initiated to unlock (UNLK*) the modules resources. The dummy cycle is initiated, by the current master, if the modules 
resources are still locked (! LKD*) after end of tenure (ENDT*) has been issued (*BGRNT* & Master & ! LKD* & ENDT*) and the arbitration bus is idle. 


Note 6: If this is the second pass of a two-pass arbitration cycle and a new request (! BRQ* or 1 MGRQ*) is generated, that request will not be allowed to compete 
until the next arbitration cycle. Note that pre-emption is allowed. 


Note 7: If Two-Pass arbitration has been selected, Parking is only possible during Phase 0 of the first pass. 
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5.0 Arbitrating for Futurebus + (Continued) 
* a "(COMPETING & PASS1) + (W & PASS2) / ICMPTS (Note 4, 5) 


| F:S* / ACOO / CN(7:0), CNP, !CNLE* FOR 20 ns 


AS* & 1 DS* & Dit & IBA_PK* & ! BRQ* 
& PASS! /IIBALCMPT*, (note 2) 
DRIVE BIT ON PARALLEL DATA BUS 


PHASE 1 
DECISION PHASE 
APO, ! AQO, ARO 


(Note 3) 
(Note 1) IDI* 


IDLE BUS ARBITRATION (IBA) NORMAL PHASE 1 


PROGRAMMABLE SKEW, PS(1:0), TIMED OUT 1ARI/START 1 MICRO=SECOND PHASE 2 TIMER 


I ARO (Note 6, 7) 


PHASE 2 
COMPETITION PHASE 
APO, ! AQO, ! ARI 
(SEE PHASE 2 ARBITRATION 
STATE DIAGRAM) 


TL/H/10747-17 
FIGURE 7b. Phase 1 Arbitration State Diagram 


Note 1: Idle Bus Arbitration during Phase 1 is not an internal state of the Arbitration Controller. It is shown in this state diagram only to give a better understanding 
of Phase 1 arbitration. 


Note 2: One bit on the parallel data bus is driven by external logic (the arbitration controller only drives the ! IBA_.CMPT output) only if IBA is supported by the 
module. Note that the arbitration controller does not require AS* & | DS* & DI*, external logic will require these conditions (from the Futurebus+ specification). 


Note 3: If a module does not want [BA to select a new master external logic around the arbitration controller will drive | di*. This transition is shown in this diagram 
to allow a clearer understanding of how IBA relates to normal arbitration. . - 


Note 4: Competing = "I BRQ* + | MGRQ* + Dummy Cycle”, W = W bit of STATUS register. 

Note 5: These Requests must have occurred before APO was asserted or they will not compete until the next arbitration cycle. 

Note 6: The possible metastable condition of “(1 BRQ* + |! MGRQ* + Dummy Cycle) occurring at the same time as API’ must be resolved before driving ! ARO. 
Note 7: All conditions shown above the Phase 1 state must be completed before driving |! ARO. 
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5.0 Arbitrating for Futurebus + (Continued) 
/ \ABLRD* AFTER 30ns 


/ FSTR® 


IIBALCMPT* & IIBA_S* & (ote 2) /!ACOO 
t, NOT EXPIRED & Di* / 1 BGRNT* 


PHASE 2 
COMPETITION PHASE. 
APO, ! AQO, ! ARI 


(Note 1) 


IDLE BUS ARBITRATION (IBA) NORMAL PHASE 2 


IWIN®_GT® & 1 jus TIMER NOT EXPIRED / Ago Net 5) 
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PHASE 3 
ERROR CHECK PHASE 
"APO, AQO, ! ARO 
(SEE PHASE 3 ARBITRATION 
STATE DIAGRAM) 


TL/H/10747-18 
FIGURE 7c. Phase 2 Arbitration State Diagram 


Note 1: Idle Bus Arbitration during Phase 2 is not an internal state of the Arbitration Controller. It is shown in this state diagram only to give a better understanding 
of Phase 2 arbitration. 

Note 2: Bus Grant (! BGRNT*) is driven by the arbitration controller during Phase 2 only if IBA was successful for this module and the Arbitration settling time (ta) 
has not expired. Also, DI* is shown here to indicate that IBA is allowed to select a new Master. DI* is not an Arbitration Controller signal. DI* is represented here for 
completeness shake only to give a better understanding. Also, external logic will release the bit on the Parallel data bus. 


Note 3: This transition to Phase 3 occurs when this module was competing, its arbitration settling time expired, and the one micro-second Phase 2 error timer has 
not expired. ; tog 





1-25 


SZ8esa 





DS3875 


5.0 Arbitrating for Futurebus+ (continued) 


compeTinc ‘Note 7) & 1 wine_cT* / / AB_RD* AFTER 20ns 
FIBA CMFUS Sc BA SE SET W (STATUS REG. BIT FOR WINNER) ‘N°? 6) 
PASS1 / AC10 (Notes 2,6) 


(Note 8) 


ACII / 1! APO 


PHASE 3. 
ERROR CHECK PHASE 
APO, AQO, ! ARO 


(Note 1) F 
IDLE BUS ARBITRATION (IBA) NORMAL PHASE 3 


'IBA_CMPT* & [(!CMPT_BRQ* & BRO*) + 
! IBA_S* & (Note 3) (! ree fic & MSGRQ*)) 
& PER* / ACOO, AC10, 
AC1O & AS / 1APO a taped) 
!AS & NO_ERRORS / (Note ' 
! APO 
1ST PASS & COMPETING un 
1 ys TIMEOUT + !PER* / !APO, ACOO, IWIN_*GT® & 2ND PASS 


AC10, | ERINT® REQUIRED / AC10, !APO 


PREEMPTION CASES 
(REFER TO TABLE V) 


7 acto, 1apo “Note 4) 


IAPI/RESET 1 zs TIMER 


PHASE 4 
MASTER RELEASE PHASE 
1 API, AQO, | ARO 
(SEE PHASE 4 ARBITRATION STATE 
DIAGRAM) 


mS TL/H/10747~19 
FIGURE 7d. Phase 3 Arbitration State Diagram 


Note 1: Idle Bus Arbitration during Phase 3 is not an internal state of the Arbitration Controller. it is shown in this state diagram only to give a better understanding 
of Phase 3 arbitration. 


Note 2: AC1O is asserted to cance! the transfer of bus tenure if IBA was successful. 
Note 3: AS is asserted if IBA was successful for this module. 


Note 4: A Module will pre-empt another module if it did not compete i in the present competition yet its arbitration number is higher than the current winner. In this 
instance the pre-emption module will assert AC10O to cancel the transfer of tenure and allow a new competition to take place. Preemption i is not alowed! in the 1st 
pass when the arbitration cycle consists of two pass. 


Note 5: If a module that competed and won no longer is sound: a bus or message request, AC10 will be driven to cancel the transfer of tenure ane ! ERINT* be 
driven to indicate an error has occurred. 


Note 6: ACIO (if IBA was successful) and the W STATUS bit (if competing and won) must be asserted before driving ! APO. 
Note 7: Competing = ! BRQ* +! MGRQ* + Dummy Cycle. 
Note 8: All actions in this phase are performed after the arbitration number is latched. 
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5.0 Arbitrating for Futurebus+ (Continued) 
IMASTER/START 1 zs MASTER RELEASE TIMER 


PHASE 4 
MASTER RELEASE PHASE 
! API, AQO, ! ARO 


(Note 2) 


ACI / ARO 
IMASTER & ARI / ARO 
MASTER & I CANCEL & RECEIVED !ENDT* / ARO 
No_waster "Nt* 5) & tempt a 1WIN®_GT*/ARO 
MASTER & CANCEL / AC10, ARO 


PHASE 5 
TRANSFER TENURE PHASE 
! APO, AQO, ARO 
(SEE PHASE 5 ARBITRATION STATE DIAGRAM 
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TL/H/10747-20 
FIGURE 7e. Phase 4 Arbitration State Diagram 


Note 1: The Arbitration controller releases its arbitration number on Futurebus+ by negating CMPT* to the arbitration transceiver. 
Note 2: If no master or master error occurred, on timeout, assert ARO so the master elect may take over the bus. 
Note 3; No_Master = No Current Master of Futurebus+ during Powerup or Initialization. 
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5.0 Arbitrating for Futurebus+ (Continued) 


IBACMPT® =I LKD® & LACH & LACO! / !UNLK# (Note 1). 


a / DUMMY CYCLE & ~UNLK* / 1AQ0 


PHASE 5 | ACI /1AQ0 
TENURE TRANSFER PHASE 
!APO, AQO, ARO 


UPDATE ROUND ROBIN BIT ETXCN1(RR) 1 N™* 2) 


¢ (Note 3)» 1 acol& 1 ACH " W RECEIVED MESSAGE / (IMGINT® & FSTR*® & NO 


Note 4 ERRORS & 2ND PASS & OTHER MODULE MESSAGE 
7 vecrnt \* 4) waster, raga" 2 Note 2 


+ | PFINT*, tago! 


IMGRO® & W (Note 3) & 1 ACO & LACOL & LACH & sw (Note 3) 
SECOND PASS OF TWO=PASS ARBITRATION / 7 \MASTER, 1AQ (ete 2) 


IMSGTX#, 1AQo (Note 2) 


PHASE 0 
IDLE PHASE 
! APO, ! AQI, ARO 
’ (SEE PHASE 0 ARBITRATION STATE DIAGRAM 


TL/H/10747~-21 


FIGURE 7f. Phase 5 Arbitration State Diagram 


Note 1: Unlock this modules resources if its resources were locked and this is restricted mode, one pass arbitration, or the second pass of a two-pass arbitration 
cycle. : : 


Note 2: Only update Master status bit, TXCN1 (RR), | MGINT*, FSTR*, | PFINT*, |! BGRNT*, or ! MSGTX* given that this is restricted mode, one pass arbitration, or 
the second pass of a two-pass arbitration cycle. 


Note 3: W = W bit in the STATUS register, C = C bit in the STATUS register. 
Note 4: ! BRGNT* is not issued if this is a dummy arbitration cycle, initiated by the arbitration controller to unlock resources. 
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Arbitration Controller Internal Register Bit Changes 


TABLE Ill. Restricted Mode Arbitration or Unrestricted Mode Arbitration 
(One Pass, or Second Pass of Two Pass) 


Modules Category | Txcn1 | STATE RXMsG| cLRERI | © RDG! 
during Arbitration | . RR - A(0:7) 


Reset, Set 





X, 5 
Xx, 5 
X, 5 
X, 5 


Competitor 

By-Stander 

Sending Message 

Receiving Message 

Pre-Emption 

IBA | 5 
(Note 4) 


X, 5 


Parking 
(Note 3) 
_ Note: The number shown within the box defines the arbitration phase where the particular bit may change state. 

Note 1: Note that the STATE Register is updated in each Phase of Arbitration. . , 

Note 2: This is the new Masters Competition Number. 

Note 3: Parking is only a Phase 0 event. 

Note 4: The RR bit is only updated on the New Master. : 

Note 5: The M bit is updated if IBA succeeded during Restricted Mode, or Unrestricted Mode (One Pass or the First Pass of Two Pass Arbitration). 

“X” means that any Phase can update this bit (or bits). ian ne . ; 

‘‘” is used in the table to depict the condition where a particular Status bit is Reset and where it is Set (Ex. 0, 1 means that this Status bit is Reset in Phase 0 and 

Set in Phase 1). ‘ 


‘is used in the table to depict the condition where a particular Status bit may change within several sequential phases (Ex. 2-4 means that this Status bit can 
change in Phases 2, 3, or 4). 


TABLE IV. Unrestricted Mode, First Pass of Two Pass Arbitration 


CLRMGI 
CLRPFI 


State RXCNO 


All Bits RXMSG | CLRERI 


Modules Category | TXCN1 


All Bits 


during pineuion RR. (Note 1) rwle lm (Note 2) ufo) | aR] PO] Pt | A(0:7) | Reset, Set Reset, Set 





X, 5 
X,5 
X, 5 
X, 5 


Competitor 
By-Stander 
Sending Message 
Receiving Message 
Pre-emption 

IBA 


Parking (Note 3) 
Note: The Number shown within the box defines the arbitration phase where the particular bit may change state. -" 
Note 1: Note that the STATE Register is updated in each Phase of Arbitration. 
Note 2: This is the new Masters Competition Number. 
Note 3: Parking is only a Phase 0 event. 
Note: “X” means that any Phase can update this bit (or bits). 
Note: “',”’ is used in the table to depict the condition where a particular Status bit is Reset and where it is Set (Ex. 0, 1 means that this Status bit is Reset in Phase 0 
and Set in Phase 1). 
Note: “'-‘‘ is used in the table to depict the condition where a particular Status bit may change within several sequential phases (Ex. 2-4 means that this Status bit 
can change in Phases 2, 3, or 4). 


xX, 5 
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TABLE V. Pre-emption 


Category Pre-emption Case Result 
Messages no pre-emption 


, message vs anything else pre-empt: no number 
. , , comparison 


| anything vs message oo no pre-emption 


Restricted Mode . restricted vs restricted . pre-empt if: 
TXCN1 > RXCN1 


restricted vs message no pre-emption 


Unrestricted Mode 1 pass vs 2 pass pre-empt: no number 
ae ; comparison 
; 1 pass vs 1 pass pre-empt if: 
TXCN1 > RXCN1 


2 pass vs 2 pass pre-empt if: 
TXCNO > RXCNO 
and 
TXCN1 > RXCN1 


Note: All pre-emptions take place in the second pass of arbitration or the only pass of arbitration. 


I 
| 


Fin: -— 


IBA_CMPT® 
IBALS* 
BGRNT* 
AS_CANCEL 

' | 

I I 

| | 


TL/H/10747-29 
FIGURE 12a. IBA—Restricted or Unrestricted Single Pass 
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PHASE 0 


| 
| 
eno® ! . Seva e iF a' wae a 


IBA_CMPT* 
_IBALS* 
BGRNT* 


AS_CANCEL 


Feaucssaraiare 


TL/H/10747-30 


FIGURE 12b. IBA—Unrestricted Two Pass 


6.0 The DS3875 Arbitration Controller Support 


of Locking and Unlocking 


The DS3875 Arbitration Controller supports locking and un- 
locking of the modules resources whether it is a master or a 
slave (see Figure & ). 

If the Module becomes master and wishes to lock the 
slave’s resources, it should assert LKD* (! LKD*) after re- 
ceiving bus grant (! BGRNT* from the arbitration controller), 
and drive the appropriate lock command during the parallel 
bus: connection phase. This lock command (during the con- 
nection phase of the parallel:bus) will cause the selected 
slave module(s) to assert lock (! LKD*) to their arbitration 
controller. Once the module has finished its parallel bus 
transactions it will assert end of tenure (! ENDT*). 


If the Master is in, or enters, Phase 0: 
. with end of tenure issued, 
. no other module has started an arbitration competition, 
. LKD* is still asserted, 
. anew bus request (! BRQ*) has not been issued 


it will start a dummy arbitration competition cycle to unlock 


’ all resources on the bus that were locked. The dummy cycle 
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will proceed through the normal arbitration competition ex- 
cept that no bus grant will be asserted if the module wins 
the arbitration competition. 

If another module has initiated an arbitration competition the 
master will participate in the competition and no dummy cy- 
cle will be initiated. 

During Phase 5, upon successful completion of the arbitra- 
tion cycle unlock will be asserted (| UNLK*) until the lock 
input is negated. 





SZ8€Sa 





DS3875 


ARBITRATION. PHASE 


PARALLEL BUS 


BRQ* 
BGRNT® 
ENDT* 
LKD* 


UNLK* 


ARBITRATION PHASE 


PARALLEL BUS 
BRQ* 


BGRNT* 


ENDT* ~ 


LKD* 


UNLK* 


A. Master Module Lock and Unlock Timing Diagram 


DUMMY 
ARBITRATION 


CONNECT DATA DISCONNECT XX CONNECT DATA DISCONNECT XK =f 


TL/H/10747-22 
B. Slave Module Lock and Unlock Timing Diagram 


DUMMY 
ARBITRATION 


CONNECT DATA DISCONNECT CONNECT DATA DISCONNECT 


TL/H/10747~23 


FIGURE 8. Master and Slave Lock and Unlock Timing Diagrams 
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7.0 Register Description 


TOTAL MEMORY MAP | 
ADDRESSABLE REGISTERS HARDWIRED REGISTER 


0000 | TXCNO (R/W) ALL 1s 
17 ) 8 
0001 | TXCN1 (R/W) 
7 0 Legend: 
; : Register Type 
0010 | TXMSG .. (R/W) : 
7 ; 0 Register | Register_Name (Read/Write) 
7 Address 
0011 | CTRLi . (R/W) ADD(3:0) | MSB LSB 
7 0 
0100 | CTRL2 " (R/W) 
7 0 ; 
0101 | CTRL3 a uh (R/W) oO, 
7 0 
0110 | STATE . (R) 
> 7 0 
0111 | STATUS : (R) 
7 . . 0 
RXCNO (R/W) 
7 : 0 
1001 | RXCN1 - (R/W) 
7 , 0 
0 
0 


1010 | RXMSG - (R/W) 
7 ' 


1011 


1000 


1100 


CLRERI . (R/W) 
7 . 

CLRMGI . ; (R/W) 
Z 0 
1101 | CLRPFI (R/W) 

7 0 


1111 | REV NO. (R) 
7 0 
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7.0 Register Description (continued) 
This section describes the addressable registers and the ALL1s hardwired register. 


7.1 ALL1S \ 


_ This register carries the first word of an arbitration message e (nitty. 
7.2 TXCNO (ADD(3:0) = 0000) 


For the Unrestricted Mode, this register stores the pass 1 apiraton number of a two pass arbitration. (CN7 = ). Defaults to 
h’00. tot 


‘DeseaDben - 


Priority field of the arbitration number. 


This bit is fixed at zero as specified in the Futurebus + specification for the pass 1 number of a 
two pass arbitration. 


Note: The Parity bit CNp for the arbitration number is internally generated during the time the host writes the numbers into the controller.. The odd ca as 
specified in the Futurebus+ specifications is generated. CNp is set to one when even number of ones are present in the arbitration number. 


7.3 TXCN1 (ADD(3:0) = 0001) 


For the Unrestricted Mode, this register stores the pass 2 arbitration number of a two pass arbitration, or stores the single pass 
arbitration number (CN7 = 1). This register also stores the arbitration number used in the Restricted Mode. Defaults to h’10. 


7 6 5 4 3S 2 1 0 
ve ———————E— 
— Symbol ~ Description 


Uniqueness field of the arbitration number. 


Round Robin bit of the arbitration number. Note: This bit is eer during phase 5, upon the 
successful transfer of tenure. See Table Ill. 


Priority field of the arbitration number. If configured as a a two pass -arbitor, PO; is part of P(0:7). If 
configured as a single pass arbitor, PO is the ipronty: field. If sfconfiguied to to arbitrate in restricted 
mode then PO is part of P(0:1). 


This bit is fixed at one as specified in the spec for the pass 2 number of a two pass arbitration, 
and for the single pass arbitration number. This bit is P1 for the restricted mode arbitration 
number. 


Note: The Parity bit CNp for the arbitration number is internally generated during the time the host writes the numbers into the controller. The odd parity as 
specified in the Futurebus+ specifications is generated. CNp is set to one when even number of ones are present in the arbitration number. 
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7.0 Register Description (Continued) 


7.4 TXMSG (ADD(3:0) = 0010) 
This register holds the arbitration message to be transmitted. Defaults to h’ff (Powerfail). 


7 6 5 4 3 2 4 : 0 
| Bit | Symbol _| Description 





A(0:7) Arbitration message to be sent. 


Note: The Parity bit CNp for the arbitration number is internally generated during the time the host writes the numbers into the controller. The odd parity as 
specified in the Futurebus+ specifications is generated. CNp is set to one when even number of ones are present in the arbitration number. ; 


7.5 CTRL1 (ADD(3:0) = 0011) 

Control register 1. PS(1:0) programs the delay needed to ensure the assertion of the most significant 1 in CN(7:0) after compete 
is issued before the release of ar*, or, during IBA, this delay ensures there is sufficient time to assert the AD/DATA lines before 
the release of ar*. PC(5:0) programs the internal divider to receive a clock input from 2 MHz to 40 MHz in steps of 1 Mz. During 
chip reset, (RST*) the divider is set to receive a clock of 20 MHz. This input clock divider should be programmed during 
initialization for the desired frequency. Defaults to h’14. 


7 


6 5 4 3 2 1 0 
| pst | pso | pcs | pcos | pos | pce | por | Po | 
| pit | symbol _| % Description | 


PCO-PC5 Programs the internal input clock divider to receive a clock from 2 MHz to 40 MHz, in steps of 
1MHz... 


The binary value of the clock frequency is coded with PC5 being the MSB. For example, to 
program the divider to receive a 25 MHz signal PC5:PCO bits are: 011001. To program the 
divider to receive a 10 MHz signal PC5:PCO bits are: 001010. 


PSO-PS1 Programs the chip to chip skew when releasing AR* in phase 1.. 
PSO PS1 DELAY , 


0 0 Ons 


0 1 5ns 

1 0 15ns 

1 oo 25 ns 
This delay ensures that after compete is issued to the transceiver sufficient time is allowed for 
the number to be put on the bus before releasing AR’. It also provides a means to provide 
sufficient time for asserting AD/DATA lines during IBA before the release of ar*. 
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7.0 Register Description (Continued) 


7.6 CTRL2 (ADD(3:0) = 0100) : at 
Control register 2. This register stores two parameters FS__(Fast/Slow) and DS__(Restricted/ tinnsetteiceh that’ ectiare the 
controller to operate in the chosen mode. PD(5:3) selects one of aon uke for the fast module and PD(2:0) selects one of 
eight Gelays for the slow module. Defaults to h’00. oat cor ci re ; 


-. Description 


"Programs the arbitration delay thatis timedina competition. These bits give a total of. 
16 selectable delays, 8 fast and 8 slow. PDO-PD2 select the slow module’s delay and ; 
PD3- PDS select the fast module’s delay. 4 th hie. 
__ (PD5 PD4 PD3) Fast... (PD2PD1 PDO) "Slow 
-. . 000. . +.60-., ... 000. . ,. 80 
001... » SeeBOe cree & MOOT... 2 ee 9 Oe. 
010 “~. 100 — 010.0 we ot. 160.0: 
011 120 O11 200 
“400 en [de Se Ek ADO caer oe BEQ ee: 
101, 160 = ‘01 +280 
110. 180... 2. 110002 0. 820. 
111 200 ib Meer es 360° 
: Restricted/Unrestricted: : 
Configures the controller to arbitrate in unrestricted frie 
_Configures the controller to paloitate in restricted mode. 


\ Fast/ Slow: 
- Configures the canticllet as a slow module. 
“© Configures the controller.as a fast module. 


7.7 CTRL3 (ADD(3:0) = 0101) 
‘Defaults to h’00. 


eae ee ee 


Description 


indicates that all the required initialization is complete and the controller may accept 
requests. 


the controller will follow the normal flow of arbitration along with other modules 
(bystander). 

Double/Single 

Configures the controller to arbitrate in a single pass arbitration mode. 
Configures the controller to arbitrate in a two pass arbitration mode. 


A“one” indicates that a new GO bit has been loaded. This bit is reset automatically when the new 
GO bit takes effect. To be set by the user when the GO bit is changed. 


ND_S* A“one” indicates that a new D_S* bit has been loaded. This bit is reset automatically when the new 
|_S* bit takes effect. To be set by the user when the D__S* bit is changed. 


NCN A “one” indicates that a new CN has been loaded. This bit is reset automatically when the new CN 
takes effect. This bit is set internally when TXCN1 is accessed while the GO bit is set. 

IBA_PK* Idle Bus Arbitration/Parking: 
1 Configures the controller to do Idle Bus Arbitration. 
0 Configures the controller to do Parking. 


A “one” indicates that a test clock is being fed through the CLK pin to test the timers and counters in 
the controller. 
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7.0 Register Description (Continue) 


7.8 STATE (ADD(3:0) = 0110) 


This register contains the present state of the arbitration controller. This information may be used for testing and d debugging 
purposes. Defaults to h’01. ; 


7 6 5 4 3 2 1 0 
posts | sm sts | sta] sm | st 


| Bit | symbot_| Description 





| 0-5 | ST(0:5) These bits indicate the current phase of the arbitration controller. 


7.9 STATUS (ADD(3:0) = 0111) 


This register contains status information and internal counter/divider test bits. The M, C, W bits default to zero. The counter test 
bits may be evaluated when feeding in a test clock. 


= Description 


CT(0:2) Counter test bits: : 
CT2—set to one when 1 ps timeout occurs. 
CT1—set to one when divide by 40 divider has divided 40 times. 
_CTO—set to one when divide by n divider has divided n times. 


Win attribute of the module. A ‘‘one” indicates that the module is the winner of the current 
arbitration cycle/pass. 


Competitor attribute of the module. A ‘‘one” indicates that the module is competing for the bus. 


Master attribute of the module. A “one” indicates that the module is the current master of the 
bus. 


7.10 RXCNO (ADD(3:0) = 1000) 
This recister stores the received pass 1 apanon number of a two pace’ number (CN = 0). Defaults to h’00. 


| Bit | Symbol Description sf = 28 





0-6 P(1:7) Priority field of the current master/master elect arbitration number. This register is used only if 
the controller is configured to arbitrate in Unrestricted two pass mode. 

7 0 This field is fixed at zero as specified i in the Futurebus+ spec for the pass 1 number of a two 
pass arbitration. — 
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7.0 Register Description (Continued) 


7.11 RXCN1 (ADD(3:0) = 1001) 


This register stores the received pass 2 arbitration number of a two pass arbitration number, or the single pass arbitration 
number, (CN7 = 1) in the Unrestricted mode. Also this register stores the Restricted Mode arbitration number. Defaults to h’10. 


. 7 6 5 4 3 2 1 0 
[over | po TR | ts Ts te | Tl 


al Symbol Description 


Uniqueness field of the current master/master elect. 
Round Robin bit of the current master/master elect. 


Priority field of the current master/master elect. If configured as a two pass arbitor, PO is part of 
P(0:7). If configured as a single pass arbitor, PO is the priority field. If configured to arbitrate in 
restricted mode then P0 is part of P(0:1). 


This field is fixed at one as specified in the spec for the pass 2 number of a two pass arbitration, 
and for the single pass arbitration number. This bit is P1 for the restricted mode arbitration 
number of the current master/master elect. 


7.12 RXMSG (ADD(3:0) = 1010) 
This register stores the received non-powerfail arbitration message: Defaults to h’00. 


| Lew | 


[en | symbot [eserption 





HOF | A(0:7) Non-powerfail arbitration message received from another module. 


7.13 CLRERI (ADD(3:0) = 1011) 
Error bits to indicate Parity, no BRQ/MGRQ or a timeout error. A dummy write into this register clears the error interrupt and all 
the error bits. Defaults to h’00. 


Description 


Error bit 3: indicates to the winner of the arbitration cycle that BRQ/MGRQ anal is no longer 
present. 


Error bit 2: indicates a timeout error. 
Error bit 1: indicates a Parity error. 


7.14 CLRMGI (ADD(3:0) = 1100) 


7.15 CLRPFI (ADD(3:0) = 1101) 
A dummy write into these registers clears the respective interrupt. 


7 6 5 4 


| it | symbol | escription 





ep 
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7.0 Register Description (Continued) 


7.16 REV NO. (ADD(3:0) = 1111) 
Revision number of the controller. 


7 6 


a ea 


8.0 Programming Registers 


During power up, the registers should be initially pro- 
grammed. The host may read/write to/from the register 
block at any time. The host may select to write data into the 
register either on the falling edge of DSACK* or on the ris- 
ing edge of CS*. A zero on the SEL input pin configures the 


controller to latch in data on the falling edge of DSACK* 
while a one sets the controller to latch in data on the rising 


edge of CS*. Refer to the timing diagrams (see Fi igures 72a, 
b,c). 


8.1 HOST WRITE CYCLE USING FALLING EDGE OF 

DSACK* (Figure T2A) 

1. R_W* signal is negated. 
ADD(3:0) contains the address of the register to be ac- 
cessed. (Note: The setup time with respect to CS* must 
be satisfied.) 

. CS* is asserted (! CS*). 

. When the proper setup time of CS* to the rising edge of 
clock is met and CS* is low for at least 3 clock cycles, 
then DATA(7:0) will be latched into the register, by the 
falling edge of DSACK*, on the 3rd rising clock edge 
after the assertion of CS*. If the CS* setup time is not 
met‘ and CS* is: low for at least 3 clock cycles, then 
DSACK* is asserted and the data (DATA(7:0)) is latched 
into the arbitration register on the following 3rd or 4th 
rising clock.edge after the assertion of CS*. If CS* is 
negated (CS*) before 3 clock cycles, then DSACK* is 
not generated and as a default, DATA (7:0) is latched 
into the arbitration controller register on the rising edge 
of CS*. 


. Host negates CS*. 


. Arbitration Controller negates DSACK* (DSACK*) if it 
was asserted. 


8.2 HOST WRITE CYCLE USING RISING EDGE OF cs* 

(Figure T2b) 

1. R_W* signal is negated. 
ADD(3:0) contains the address of the register to be ac- 
cessed, (Note: The setup time with respect to CS* must 
be satisfied.) 

. CS* is asserted (! CS*). 

. DSACK* is asserted (! DSACK*) by the Arbitration Con- 
troller when CS* is asserted for at least three clock cy- 
cles. If CS* is negated (CS*) before three clock cycles, 
DSACK* is not asserted. The DSACK* signal may be 
used or ignored by the system designer, in this case. 

. Host negates CS*. DATA (7:0) which satisfied the setup 
time to the rising edge of CS* is latched into the arbitra- 
tion controller register. 

. Arbitration Controller negates DSACK* (DSACK*) if it 
was asserted. 
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8.3 HOST READ CYCLE (Figure T2c) 

1. R_W* signal is set high. 
ADD (3:0) contains the address of the register to be ac- 
cessed. (Note: The setup time with respect to CS* must 
be satisfied.) 


. CS* is asserted (! CS*). 


. The data will be available on the DATA (7:0) bus within 
the access time specified in the AC timing section. 


. The Data Strobe ACKnowledge (DSACK*) signal is gen- 
erated as an acknowledge to the host signifying the va- 
lidity of the accessed data. DSACK* may be used to in- 
sert WAIT states to the host during a host read cycle. 
When the proper setup time of CS* to the rising edge of 
clock is met and CS* is low for at least three clock cy- 
cles, DSACK* is asserted (! DSACK*) on the 3rd rising 
clock edge after the assertion of CS*. If the CS* setup 
time was not met and CS* is low for at least three clock 
cycles, then DSACK* is asserted on the following 3rd or 
4th rising clock edge after the assertion of CS*. If CS* is 
-not low for at least 3 em cycles. DSACK?® ji is not gener- 
ated. a 


. Host reads data and negates CSs* (CS*). 


6. Arbitration Controller negates DSACK* Shes) if it 
was asserted. 


9.0 Clock/Timer/Delay | Lines 


(See Figure 9.) The input clock signal (CLK) to the arbitra- 
tion controller is assumed to be.a clock from 2 MHz to 40 
MHz, in steps of 1 MHz. 


The clock signal is also used for synchronization purposes 
during read or write transfers. This is accomplished by syn- 
chronizing the DSACK* (Data Strobe Acknowledge) output 
from the Arbitration Controller to the clock during arbitration 
controller register reads or writes. 


The binary value of the input clock (CLK) frequency is load- 
ed into the CTRL1 [5:0] register. This value is used to pro- 
gram the divide by n counter to scale the input clock down 
to a 1 MHz clock internally. The PLL ring oscillator also has 
a clock divider (divide by 40) to scale it down to a 1 MHz 
clock. These two clocks are compared and the difference 
between the two clocks is fed back to the ring oscillator to 
cause it to lock onto the appropriate frequency. 

The PLL is used to generate several programmable delay 
lines and the 1 ws Timer used during phase 2 and phase 4. 
The 1 ps timer, divide by 40 divider and divide by n divider 
can be tested to determine proper functionality. Refer to 
Testing the Arbitration Controller and Register Description 
sections for details. 
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9.0 Clock/Timer/Delay Lines (continued) 


PLL 


PHASE COMPARATOR, CHARGE PUMP 
AND RING OSCILLATOR 


DIVIDE BY N 


DIVIDE BY 40 


FIGURE 9. PLL, Timer and Test Circuitry 


10.0 Reset/Initialization/Power Up 


Two distinct input reset pins are available on the Arbitration 
Controller, RINT* (Bus Reset and Initialization) and RST* 
(Power Up Reset). These signals are activated by the mod- 
ule upon detecting either RE* (in an appropriate condition) 
on Futurebus+ or reset from the host or the Protocol Con- 
troller. Both these signals are asynchronous inputs so that 
the reset function is performed immediately after the signal 
is asserted. 


RINT* may be asserted by external logic from RE* being 
asserted for at least 2 ms or some other appropriate condi- 
tion. When RINT* is asserted (! RINT*): 
. the arbitration controller is placed in phase 0 
. all outputs of the arbitration controller are negated, ex- 
cept ARO 
. The following registers are cleared: RXCNO, RXCN1, 
RXMSG, CLRERI, CLRMGI, CLRPFI, and M C W bits of 
the STATUS register 


. STO bit is set in the STATE register 


TCSEL BIT 
(CTRL3 (71) 


DIVIDE BY 2 


1-40 


1 ys TIMER 
(DIVIDE BY 20) 


SIGNAL FOR 1 ys 
TIMEOUT 


__ TL/H/10747-24 


5. Contents of other registers remain, except for the round 
robin (RR) bit of TXCN1 which is reset. 


The rising edge of RINT* will release the arbiter from phase 
0. This reset signal should be used during Futurebus+ ini- 
tialization. : 


When RST* is asserted (! RST*):. ° 
1. all outputs of the arbitration controller are negated 


2. the registers are set to default values as given in the 
register description, Section 7. 


The rising edge of RST* will cause ARO to be asserted 
causing the arbiter to be in phase 0. This reset signal should 
be used during power-up and live withdrawal. 


Figure 10 illustrates how the reset and initialization signals 
may be used during power up. While powering up, when 
RINT* is asserted for 100 ms—200 ms, the registers may be 
programmed. BRQ* should not be issued until after 10 ms 
after the register CTRL1 is programmed giving the PLL a 
sufficient time to lock onto the CLK signal. 





10.0 Reset/Initialization/Power Up (Continue) 


REFER TO FUTUREBUS+ SPECIFICATION 
FOR POWER UP = 100 TO 200 ms 


FIGURE 10a. Programming Registers: After Power-Up 


DURING ! 


taimin = 50ns 


ba 
1 BEGIN PROGRAMMING 


; REGISTERS 
TL/H/10747-25 


! 
RST* POWER UP PROM hese eae, Gane POINT A 


REFER TO FUTUREBUS+ SPECIFICATION 
FOR BUS INITIALIZATION = 2 TO 30ms 


i] taaMIN = 50ns 


POINT B 
1 
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FIGURE 10b. Programming Registers: During Bus Initialization 


cs* 


ADD(3:0) 


BRQ* OR MGRQ* 


(0011) 
CTRLI 


aD 


DY 


TIME NEEDED FOR 
PLL TO LOCK = 10 ms 
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FIGURE 10c. PLL Lock Period 


11.0 Live Insertion 


The arbitration Controller supports live insertion (see Figure 
71). When a module is being live inserted into an active 
Futurebus+ system it will be powered up and reset. The 
live inserted module will reset it’s arbitration controller with 
the RST* input and will drive re* on the Futurebus+ back- 
plane. . 

RE* asserted will cause all active Futurebus+ modules to 
release their bus lines to prepare for live insertion to the 
Futurebus+ backplane. . 


When all the active Futurebus+ modules detect RE* as- 
serted, they should assert HALT* to their arbitration control- 
ler and limit the current parallel bus transaction to 128 ys. 
The active modules will then remain in Phase 0, upon com- 
pletion of the current control acquisition cycle, until HALT* 
is negated. 


When the live inserted module detects both: 


1. the Parallel bus in the Idle state (AS* and AKf negated), | 


2. the arbitration bus lines in Phase 0 
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for 1 ws then it should assert ai* (protocol controller) and 
negate the RST* input. The arbitration controller will assert 
ARO upon detecting the negation of RST*. These actions 
will complete the Futurebus+ alignment. The live inserted 
module will then be in arbitration Phase 0; thus, aligned with 
the other live modules. Then the live inserted module will 
negate re*. 


When the active modules detect the negation of RE* they 
negate the HALT* input to their arbitration controllers, thus 
allowing arbitration competition to proceed. 


At this point, the live inserted module can only participate as 
a by-stander during the arbitration competition cycle until it 
is programmed and 10 ms has elapsed (PLL lock on time). 
Once the 10 ms has elapsed the module can enable arbitra- 
tion competition by setting the GO bit in CTRL3. At this time 
bus requests (BRQ*, MGRQ"*) can be accepted to join com- 
petition for the parallel bus. 





SZ8€Sa 





DS3875. 


11.0 Live Insertion (Continued) 
LIVE INSERTED MODULE 


RST* 


re* 


ACTIVE MODULES 


RE* . \ 
— 


HALT# we 


| eal , 
ne Se 


bLIT IIIT ITI ILS, 


FIGURE 11. Live Insertion 


12.0 Live Withdrawal 


When a module is notified to be live withdrawn it will: 

1. complete any tasks currently in progress 

2. inhibit itself from participating in any more bus transac- 
tions (becomes a by-stander) 

The module can withdraw from the arbitration protocol in 

one of three phases: 

1. During phase 0 by repaiie ARO 

2: _During phase 2 by negating APO 

3. During phase, 4 by negating AQO 

This may be achieved in the DS3875 by i issuing the HALT* 

signal, then when it is observed that the arbitration control- 

ler is in Phase 0, asserting the RST* signal to cause all 

outputs of the arbitration bus to be released. The module 

may then be withdrawn from the Futurebus+ system. — 


13.0 Testing the DS3875 


The Arbitration Controller has features designed in which 
ease the testing and monitoring tasks for the user. Regis- 
ters may be. read to determine proper functionality of the 
chip. For instance, while the Arbitration Controller is operat- 
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ing, the arbitration phase can be monitored by reading the 
state register. Also to check proper operation of the 1 ps 
timer, divide by n divider, and divide by 40 divider, the 
TCSEL bit in CTRL3 register can be set so that a test clock 
may be used. This will allow the clock signal to be applied to 
the circuitry, thus disabling the internally generated signals 
that are used during normal operation. See Figure 70. To 
determine the status of the timer and dividers, Ne status 
register CT(0:2) bits can be read. 


If the user wants to check the proper operation of the CN 

port: 

Ts An arbitration number can be loaded into the CN port by 
performing a write cycle to any of the receive registers 
(RXCNO, RXCN1, or RXMSG). The Arbitration Controller 
will load the number from the CN port instead of the 
DATA port into the register upon detecting a write to any 
of the receive registers. The timing is the same as those 

_ given for the register write using the DATA port. Refer to 

Timing Section T2. 

. Next, by performing a read cycle to the register just writ- 
ten to (RXCNO, RXCN1, or RXMSG), the arbitration num- 

ber stored will be placed onto the DATA port. Thus, the 
proper operation of the CN port is sestee: 





14.0 Electrical Characteristics 
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Absolute Maximum Ratings Recommended Operating 


If Milltary/Aerospace specifled devices are required, . Conditions 
please contact the National Semiconductor Sales ; Min 
Office/Distributors for availabillty and specifications. 


Supply Voltage 6.5V 
Control Input Voltage 5.5V 
Power Dissipation at 70°C 0.6W 
Storage Temperature Range —65°C to + 150°C 
Lead Temperature 260°C 


Max 
Supply Voltage, Vpp 4.5 5.5 


Operating Free Air Temperature 0 70 


Electrical Characteristics (Notes 2 and 3) Ta = 0°C to +70°C, Vog = 5V 10% 


Symbol Conditions | min | typ | Max | Units 
Vi Minimum inputHighVotage | | | 
Vi Minimum inputLowVotage | | Tt 


Vou Voltage Output High lon: lo: for Several Drivers 
i.6., lo. 8 mA and 4mA 
Voltage Output Low lon, lo. for Several Drivers 
i.8., lo. 16 mA and 4 mA 


[sine | onmesaarceet [TT 
| StaticSupply Curent inputat Standby | || (80 


Note 1: “Absolute maximum ratings” are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply thatthe a should be 
operated at these limits. The table of ‘Electrical Characteristics” provide conditions for actual device operation. 


Note 2: All currents into device pins are positive; all currents out of device pin are negative. All voltages are referenced to device ground unless otherwise 
specified. | 
Note 3: All typicals are given for Vpp = 5V, and Ta = 25°C. 


15.0 AC Parameters 


Legend to AC Parameter Number Assignments 


Parameter Description 
Number : 


t000-t099 Phase 0 

t100-t199 Phase 1 

t200-t299 Phase 2 

t300-t399 Phase 3 

t400-t499 Phase 4 

t500-t599 Phase 5 

tAXX Reset, Initialization 

tBXX Register Access Data Port 

tCXX Register Access CN Port - Input 
tDXX Clearing Interrupts 

tEXX FIFO Strobe 

tFXX - WIN*__GT* Valid 

tGXx Message Signals 

tHXX Busrequest, Busgrant, End of Tenure 
tUXX Locked, Unlock Handshake Signals 
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AC Timing Parameters unless otherwise stated: T, = 0°C to +70°C, Voc = 5V £10% 


All transitions are specified after the Input signals are stable and valid for evaluation. This table will describe the 
parameters as given In the following pages. All values are given In nanoseconds (ns), unless otherwise stated. 


Number| Symbol| __————ParameterDescription =| = Min._—|| Typ | Max 
ty |taqag |BRO*AssertedtoBGANT*Asserted = “=| | St 8 
te_|taaac |AQINegatedtoAC0O, ACIONegated == | | Se] 
ta _|tapio _|APlAssertedtoAPOAsserted = | | Ct 
ts _|traap_|MGRQ*orBRO*AssertedtoAPOAsserted == | S| St 
ts_|tepap | (Dummy Cycle) ENDT" AssertedtoAPOAsserted == | S| S| 
te__|tacap _|(Consecutive Bus Requests) BRQ* AssertedtoAPOAsserted == | ||. 
ty_|turap [HALT* NegatedtoAPOAsserted = | || 
alue oad - 
tor [tome [ON te*Width = Ct Tt 
tro2_|tcns _|CNPortSetupTime CT ssd| 
tioa_|tcnz__[ARINegatedtoTRISTATECNPot | StL 
ing (IBA Mode) IBA-CMPT* Asserted to ARO Negated. Determined by 
Programmable Value : 
t105 aa Asserted to ARO Negated. Determined by Programmable 
alue : 
Programmable Value 


tior_|tapone [APO Assertedto CN-LE* Assorted. CTALSIO], “Go"Bitisset_ |_| | a2 
tios_|tapopra |APOAssertedtoCMPT*Asserted || te 
troe_|tapiec_|APOAssertedtoIBA_OMPT*Asserted | | ts 
ti1o_|tapac [APO Assertedto ACO Assorted (SiowMode) | | tt 






tzo0_|tanaanp|ARINegatedtoAB_AD' Assorted ||| 
to01 (IBA Mode) ARI Negated to IBA_S*.Ta = Arbitration Timer6o-300 | = | Ts | Ta 
to02 (IBA Mode) IBA_S* Asserted to BGRNT® Asserted a ee 
tous WIN*__GT* Asserted to AQO Asserted. After T, Expired. a ee 
teos_[taaio [AQIAssertedtoAGOAsserted =| Tt 
tas |tanaa |ARINegatedtoAGO Assorted || tt Ta | 284TH 
too7 (IBA Mode) IBA-S* AssertedtoAQO Asserted aa ee ee 
tsoo_|tacioap |ACIOAssertedtoAPONegated =| | ta 
tsor_|taswap_|AS_Cancel* NegatedtoAPONegated ||| 
ts10_|taPaBAD |APONegatedtoAB_AD*Negated || 
tszo_|taancr |AGOAsseriedtoACIO Assorted | | 80 
ten 18 
tsze |tasaap |AS_Cancel* AssertedtoAPONegated | | tt 
tss0_[tacuap [ACIIAssoriodtoAPONegated | | te 
ts4o_|tnoac |MGRG'orBRA*NegatedtoACOO,ActOAsserted | | at 80 
tser_[twanco [AGOAsseriedtoACOONegated =| | 
te [tran |AGOAsseredtoERIT Assorted | | te 
t4oo_|tapcern [APINegatedtocMPT*Negated | Tt | 
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AC Timing Parameters unless otherwise stated: Ta =. 0°C to +70°C, Voc = 5V +10% (Continued) ... 


All transitions are-specifled after the Input signals are stable and valid for evaluation. This table will describe the 
parameters as given In the following pages. All values are given in nanoseconds (ns), unless otherwise stated. 


Number | Parameter Description | Min | Ty | Max 
tuor_[tacuian ACH AssertedtoAROAsserted = | 8 
t4oa_| toanacr 18 
twos | tanto 19 
t4o7 _| teDAR 
tsoo : | taRBG ARO Asserted to BGRNT* Asserted 

tso1 | tona 
tso2_| teAFTA 
tso3_| tanto 
tsoa_| tAnABsA 
tar_|tastew 
tao |tastre | Output Reset Time - yy , 

tao _[tasTar 
ta _| trinrew 
tas _| tare 
tar_|tospw 
tee _|tosewn 
tag _|tospKa 
tex _| anos 


tps |tcspKn | CS* Negated to DSACK* Negated 
ts7 |taws-. .| R_W* Setup Time 


ter_[rsta_[rsterecoveytime SSCS 





15 


al —_ 





—_ 


~ 
A 
”n 
os 
a 
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15.0 AC Parameters (Continued) 


AC Timing Parameters unless otherwise stated: Ta = 0°C to + 70°C, Veg = 5V + 10% (Continued) 
All transitions are specified after the Input signals are stable and valid for evaluation. This table will describe the 
parameters as given In the following pages. All values are given In nanoseconds (ns), unless otherwise stated. 


| Symbol | Parameter Description | min | Typ 
AB__RD* High Time with Respect to FSTR* reol | 


ALL1* Asserted with Respect to WIN*__GT* 


PER* Asserted with Respect to WIN*__GT* TTT 
MGRQ® Negated to MGTX® Negated | Tia | ee 


ENDT* Asserted to BGRNT* Negated 


LKD* Negated to UNLK* Negated ESE 


Phase 0 Timing 





A. Transitioning Into and Out of Phase 0 


_ TL/H/10747~31 


TL/H/10747-32 


C. Negating AC10 and AC0O When Entering Phase 0 


PHASE 5 PHASE 0 


TL/H/10747-33 


D. Another Module Initiating Competition 


TL/H/10747-34 
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Phase 0 Timing (Continued) 


E. Message Request or Bus Request Initiating Competition 


TL/H/10747~-35 


F. Dummy Cycle to Generate Unlock (! UNLK*) During Phase 5 


PHASE ‘__ PHASE 0 
ENDT®* 
BGRNT* 
LKD* 


APO 


G. Consecutive Bus Requests: Parking 


TL/H/10747-36 


BROS 
BGRNT* 


ENDT* 
TL/H/10747-37 
H. HALT* Release 
: 
HALT ty 


APO 
TL/H/10747-75 


I. Consecutive Bus Requests: Non-Parking . 


BRQ* \ : 


TL/H/10747~78 
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15.0 AC Parameters (Continued) 
Phase 1 Timing 


A) TRANSITIONING INTO AND OUT OF PHASE 1 


tio2 MIN 


TL/H/10747-38 


C. IBA Mode Selected 
ARO 


IBA_CMPT* 


APO. 
TL/H/10747-39 


D. Competing 


trosMiN 


TL/H/10747-40 


E. Asserting ACOO - Slow Mode (F__S*) is Selected 


_ti10 


tyoeMIN 


TL/H/10747-41 





1-48 


15.0 AC Parameters (continueg) 


cZ8eSa 


Phase 2 Timing 
A. Transitioning Into and Out of Phase 2 
PHASE PHASE 2 


TL/H/10747-42 


B. Register Access CN Port-Input 
AQO/AQI 


ARI 
AB_RD* 


CN (7:0) 
TL/H/10747-43 


C. IBA Mode Selected-Winner of Competition 


ARI 


t 
t201 MAX call 


IBA_S* 


. t202 MAX 
BGRNT* 


D) WIN*_GT* VALID 
WIN*_GT* VALID 


AQo 


TL/H/10747~44 


E. Bystander 





TL/H/10747-45 
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15.0 AC Parameters (continued) 
Phase 3 Timing 


A. Transitioning Into and Out of Phase 3 


PHASE | PHASE 2 PHASE 4 
AQO 


API 
TL/H/10747-46 


B. AS Low and No Errors 


"PHASE 


TL/H/10747~-47 


C. Reading the Winning Competition Number (! AB__RD*) 


ee FJ 


APO” = 
AB. RDS as t310. 


. ; : TL/H/10747-48 


D. Successful IBA Competition Timing 
PHASE __PHASE 2 PHASE 4 
Ago [ee oe | 


IBA_CMPT* 


cf. - - .- -.- — 7 


j+— t320 
_ ACIO 
t324 
ts22 
AS 


E. Transfer of Tenure Inhibited 


PHASE _ PHASE 20 XQ PHASE SO) 
ACII 


TL/H/10747-49 


APO 


TL/H/10747-50 
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Phase 3 Timing (Continued) 
F. Message Request or Bus Request Being Negated During Phase 3 (If This Module was the Winner) 


PHASE 


MGRQ* OR BRQ* 
tz49 
ACOO, AC1O 


TL/H/10747-51 


t321 
APO 


: G. Second Pass Required 
PHASE __ PHASE2 XO PHASE SX PHASE 4 


AQO 
t320 
ACO 
tso0 
APO ‘a 


H. Slow Case ACO Recovery 


TL/H/10747-52 


AQO 
t344 


TL/H/10747-76 


Phase 4 Timing 


A. Transitioning Into and Out of Phase 4 


TL/H/10747~53 
B. Complete Signal is Negated 
t4o0Max 
TL/H/10747-54 


C. Inhibit Transfer of Tenure 
ACI) t 
sl 401 MAX | 
ARO 


TL/H/10747-55 
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15.0 AC Parameters (Continued) 


Phase 4 Timing (continued) 
; .y D. Module (Except Master Module) Receives ARI 
SC hpiet : wie te - eats aoa 
| teosmax 


TL/H/10747-56 
- E. End of Tenure 
ENDT* 


ARO 
TL/H/10747-57 


Phase 5 Timing - 


A. Transitioning Into and Out of Phase 5 


PHASE 4 PHASES) 


TL/H/10747-58 
B. Master Elect Gets Bus Grant When No Errors Occurred 


tsoomax 


TL/H/10747-59 


C. Message was Transmitted (During 2nd Pass-No Errors Occurred), 
Generation of Interrupt Signal, PFINT*, or MGINT*, 
Generation of Unlock Signal When Locked (! LKD*) 


ARO 


MGTX*, UNLK*, OR ANY INTERRUPT 


AQO 
TL/H/10747-60 


D. FIFO Strobe 


TL/H/10747-61 


E. Release of IBA_.CMPT* 


ARO t 
503 


IBA_CMPT* 
TL/H/10747-77 
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15.0 AC Parameters (Continued) 
T1a. RST* Signal 


XOUT 
(ANY OUTPUT 
SIGNAL) 


ARO 
, TL/H/10747-62 


T1ib. RINT* Signal 


tAaMIN 


TL/H/10747-63 


T2a. Register Access DATA Port- WRITE CYCLE USING DSACK* 


(on) 


TL/H/10747-64 
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15.0 AC Parameters (Continued) 
| T2b. Register Access DATA Port-Write CYCLE Using CS* 


~- DSACK* 


(min } 


T2c. Register Access DATA Port-Read CYCLE 


DSACK* 
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TL/H/10747-66 





15.0 AC Parameters (Continued) 
T3. Register Access CN Port-Input 


SZ8ESG 


TL/H/10747~67 


T4. Register Access CN Port-Output 


tio2MIN 


CN (7:0) 
TL/H/10747-68 


These sections are shown to give a better understanding of the CN port timing. Most of the parameters are given under the phase timing diagrams. Also a few 


parameters are added here to these diagrams. © 


T5. Clearing Interrupts 
X INTERRUPT 
(ANY INTERRUPT) 


cst . 


R_W* 


ADD (3:0) <> 
: as oe “ : . TL/H/10747-69 
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15.0 AC Parameters (Continue) 
. T6. FIFO Strobe 


PHASE 012 345, x 2 3 4 


I 
| 
FSTR* STROBE LATCHED DATA INTO FIFO ON RISING EDGE 


| eN(7:0) CWESSAGE — 


‘ : FALL THROUGH 
TL/H/10747-70 
T7. WIN*__GT* Valid 


WIN*_GT* VALID 


TL/H/10747-71 


T8. Compete Signal 


° HOSMIN 


T9. MESSAGE SIGNALS 


to1Max 
TL/H/10747~72 


These sections give some additional parameters, these are not the complete set of parameters specified for these signals. Also refer to the phase timing diagrams. 
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15.0 AC Parameters (Continued) 
T10. BUSREQUEST, BUSGRANT and END of TENURE HANDSHAKE 


BGRNT® 


tH2 MAX 
TL/H/10747=73 


T11. LKD* and UNLK* Handshake Signals 


BRQ* . 


BGRNT* 


TL/H/10747-74 
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DS3883 





A National PRELIMINARY 


Semiconductor 





DS3883 BTL 9-Bit Data Transceiver 


General Description | - Features 


The DS3883 BTL 9-Bit Data Transceiver is designed to con- ™ Meets P1194.1 standard for Backplane transceiver logic 
form to IEEE P1194.1 (BTL) as specified in IEEE P896.2 m™ Pinout is designed specifically for implementing a 







(Futurebus +). The DS3883 simplifies the implementation of Futurebus+ system 
all byte wide address/data with parity signals. Itcan alsobe = Supports live insertion 
used for the status, tag and command lines. m Low skew 






The DS3883 is one of five current devices in the Future- Controlled rise/fall time 

bus + Chip Set. The DS3886 BTL 9-Bit Latching Transceiv- Glitch free power-up/down protection 

er gives the user an option of having latches within the = Buiit-in bandgap reference provides very accurate 
transceiver. The DS3884 Handshake Transceiver has a thresholds 

pulse width selectable wired-OR glitch filter. The DS3885 m 44-pin PLCC 

Arbitration Transceiver has the competition logic for the — : ; 

AB<8:0> signal lines. The DS3875 Arbitration Controller m 44-pin PQFP reduces board real-estate 
supports all the required and optional modes for the Future- 
bus+ arbitration protocol. It is designed to be used in con- 
junction with the DS3884 and DS3885. 











Connection Diagrams 






42 B1 GND 






‘| 37 80 GND 
F-] 36 Bt GND 
| 35 B1 
F-34682 
J 6 AO 
EJ 5 Vee 
Fy 4 nc 
cj] 2 NC 

44 BO 
J] 43 BO GND 
cj 44 B1 
fj] 40 B2 





33: NC NC7 






39 NC 





32 B2 GND 





38 82 GND 









31 B3 GND 37 B3 GND 








30 B3 A3 10 36 B3 


are oxo 11 DS3883V is 
28 NC Ab 12 PLCC 34.NC 
27 BA GND QVog 13 (TOP VIEW) 33 B4 GND 


26 BS GND Voc 14 









DS3883VF 
POFP 
(TOP VIEW) 












32 BS GND 









25 BS A515 34 BS 





30 BE 






24 B8 AG 16 
23 B6 GND 






29 B6 GND 


% EJ ES to EJ to Eg EJ 8 
o Pv] Nn _- 
ee ae & 8 8 22aaggcgsaegasag& & 
2 &§ 2 iT a9 ¢ gv gv @& 2 
2 2 2° 8 32 2 2 8 8 & 3 
& 8 & 





TL/F/10719-17 ; TL/F/10719-2 










Order Number DS3883V or DS3883VF 
See NS Package Number V44A or VF44B 
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Absolute Maximum Ratings (note 1) 


if Military/Aerospace specified devices are required, Storage Temperature Range , —65°C to + 150°C 
please contact the National Semiconductor Sales Lead Temperature : 
Office/Distributors for availability and specifications. (Soldering, 4 Seconds) 260°C 


Supply Voltage 6.5V 
Control Input Voltage . 6.5V Recommended 


Driver Input and Receiver Output - 6.5V - Operating Conditions 


Note: At no time including power-up shall the control input, driver Min Max Units 
input or receiver output exceed Voc + 1V. (See Note 2.) Supply Voltage, Voc 45 55 Vv 


sega ee pias , a Bus Termination Voltage (V7) 2.06 2.14 
SN rene . Operating Free Air Temperature 0 70 °C 


DC Electrical Characteristics (notes 2, 3 and 4) Ta = 0°C to +70°C, Voc = 5V +10% 


Symbol | ___—Parameter_— | Conditions| Min | Typ | Max | Units 


DRIVER AND CONTROL INPUT: (CD, T/R, An) 


eee eee i a ee 
eee ee ER ee 
PRA ee 
pvw=osv TT 100 | 
[InputDiode Camp Vottage | omp=—12ma_ | ST 12 | 


Output Low Bus Voltage (Note 5) | An = T/R = 2.4V, lo, = 80mA lo7s| 10 | 14 | 
| Output Low Bus Current An = 0.5V, T/A = 2.4V, Bn = 0,75V | || 2850 | 
Output High Bus Current An = 0.5V, T/R = 2.4V, Bn = 2.1V f {| 400 | 


An = 0.5V, T/A =24V,8n=24V,Vcc=ov] | | 100° | 


Receiver Input Threshold T/A = CD = 0.5V | 
Positive Clamp Voltage Voc = Max or OV, Bn = 1 mA | 24 | 34] 45 | 


Voc = Max or OV, Bn = 10 mA | 29 | 39 | 5.0 | 
[Negativeciamp voltage | Ioramp==t2ma || 122 | 


Voltage Output High Bn = 1.1V, T/R = CD = O.5V, low = 


Voltage Output Low T/R = CD = 0.5V, Bn = 2.1V, Io. 


|| 095 | 05 
|TR=CD=o0sVi8n=21Vilo.=emaA | | 095 | 04 | 
| OutputShort Circuit Curent | Bn=tavT/R=co=osv | ~40 | ~70 | ~100 | 


Tim=aiwew Sid Side | 


Note 1: “Absolute Maximum Ratings” are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply that the device should 
be operated at these limits. The table of “Electrical Characteristics” provides conditions for actual device operation. 

Note 2: All input and/or output pins shall not exceed Voc + 1 and shall not exceed the absolute maximum rating at anytime, including power-up and power down. 
This prevents the ESD structure from being damaged due to excessive currents flowing from the input and/or output pins to Vcc and Voc. There Is a diode 
between each input and/or output to Voc which is forward biased when incorrect sequencing is applied. Alternatively, a current limiting resistor can be used when 
pulling-up the inputs to prevent damage. The current into any input/output pin shall be no greater than 50 mA. Exception, LI and Bn pins do not have power 
sequencing requirements with respect to Vcc and QVoc. Furthermore, the difference between Voc and QVcc should never be greater than 1V at any time 
including power-up. 

Note 3: All currents into device pins are positive; all currents out of device pins are negative. All voltages are referenced to device ground unless otherwise 
specified. 

Note 4: All typical values are specified under these conditions: Voc = 5V and Ta = 25°C, unless otherwise stated. 

Note 5: Referenced to appropriate signal ground. Do not exceed maximum power dissipation of package. 





1-59 


essesd 


DS3883 


AC Electrical Characteristics 1, = 0°c to +70°C, Vog = 5V +10% (Note 6) 8 424.4 
symbol | Parameter, =| Conditions, =| Min | Typ | Max | Units 
DRIVER . = : | 


An to Bn Prop. Delay CD = OV, T/R = 3V 
(Figures 7 and 2) 


i. T/A = An = 3V 
(Figures 1 and 3) 
TRtoBn | Enable Time | CD = oV,An=sv(Figuessend9) | | 12 |_| 
Bn Rise Time 20% to 80% perro a 


Bn Fall Time 20% to 80% 


Slew Rate is Calculated . . (Figures 1 and 4) : 
from 1.3V to 1.8V F 


An to Bn Skew in the ~ (Note 7) 
Same Package ites ; 


cD toBn | 





CD to An | Disable Time | Bn = 2.1V, T/A =0V 
. Enable Time (Figures 6 and 7) 


Disable Time } Bn = 2.1V, T/R = OV 


= Enable Time | (Pures 6and 7) | 
‘T/R to An _| Disable Time | CD=0V ~ 
| Enable Time | (figures@and9) 
Disable Time | Bn = 1.1V,CD = OV | 
Enable Time | (Figures 6 and 7) 


BTL Output Capacitance (Note 8) ae ae ae 





(Notes) el 


Note 6: Input waveforms shall have a rise/fall time of 3 ns. 


Note 7: tsxew is an absolute value, defined as differences seen in propagation delays between drivers or receivers in the same package with identical load 
conditions.. - : 


Note 8: This parameter is tested during device characterization and is guaranteed by design. The parameter is tested using TDR techniques described in P1194 
BTL backplane Design Guide.. ‘ ; 


. .Note 9: This parameter is tested during device characterization and is guaranteed by design. The measurement revealed that the part will reject 1 ns pulse widths. 
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Pin Description 


Number 
of eae 


€88ESG 


Input/ 


Pin Name ue 


Description 


AO-A8 
BO-B8 
BOGND-B8GND 


TTL TRI-STATE® Receiver Output and Driver Input 
BTL Receiver Input and Driver Output 
Driver Output Ground Reduces Ground Bounce Due to High Current Switching of 
Driver Outputs. (Note 10) 
Chip Disable 
Ground Reference for Switching Circuits. (Note 10) 
’ Voc Supply for Live Insertion. Boards that Require Live Insertion Should Connect LI 
to the Live Insertion Pin on the Connector. (Note 11) 
No Connect 
Ground Referenece for Receiver Input Bandgap Reference and Non-Switching 
Circuits. (Note 10) 
Voc Supply for Bandgap Reference and Non-Switching Circuits. (Note 11) 
TR Transmit/Receive—Transmit (An to Bn), Receive (Bn to An) 
Voc Vcc Supply for Switching Circuits. (Note 11) 


Note 10: The multiplicity of grounds reduces the effective inductance of bonding wires and leads, which then reduces the noise caused by transients on the ground 
path. The various ground pins can be tied together provided that the external ground has low inductance. (i.e., Ground plane with power pins and many signal pins 
connected to the backplane ground.) If the external ground floats considerably during transients, precautionary steps should be taken to prevent QGND from 
moving with reference to the backplane ground. The receiver threshold should have the same ground reference as the signal coming from the backplane. A voltage 
offset between their grounds will degrade the noise margin. 


Note 11: The same considerations for ground was used for Voc in reducing lead inductance (see Note 10). QVcc and Voc should be tied together externally. If live 
insertion is not supported, the LI pin can be tied together with QVcc and Voc. 


cD 


= 
> 


LI 


NC 
QGND 


Z/2z 
>| > 


2 
> 


QVcc 


4 
eee : 


2 
> 


Truth Table Logic Diagram 


X = High or low logic state 
Z = High impedance state 
L = Low state 
H = High state 


TL/F/10719=1 


R, = 12.50 





, ere TL/F/10719-4 
FIGURE 1. Driver Propagation Delay Set-Up FIGURE 2. Driver: An to Bn, T/R to Bn 
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TL/F/10719-5 
_ FIGURE 3. Driver: CD to Bn 


Yo 


, - ss Switeh Position 
far ovat [eee 
o. = sopF | R= 1ko 


; TL/F/10719-6 : 
FIGURE 4. Receiver Propagation Delay Set-Up 


2.1V 
. 1,55V 
LAV = S= 


TL/F/10719-7 


. Switch Position 


\. TL/F/10719-8 


TL/F/10719-9 
FIGURE 7. Recelver: CD to An, T/R to An 


R(load) = 5002 R(load) = 12.50 


C(load) = 50 pF i ea = 30 pF 


_ TL/F/10719-18 
FIGURE 8. T/R to An, T/R to Bn 


= bs TL/F/10719-19 
FIGURE 9. tpy.(T/R to Bn), tpzi(T/R to An) 
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GA National 


Semiconductor 


PRELIMINARY 


DS3884 BTL Handshake Transceiver 


General Description 


The DS3884 Handshake Transceiver is designed to con- 
form to IEEE P1194.1 (BTL) as specified in IEEE P896.2 
(Futurebus +). The DS3884 simplifies the implementation of 
all handshake signals which require wired-OR glitch filtering. 
The DS3884 is a six-bit wide device. Three of the six receiv- 
ers have an additional parallel wired-OR glitch filter receiver 


as shown in the logic diagram, giving a total of 9 receiver. 


outputs. 

Two pulse selection pins on the DS3884 give four different 
settings for the glitch filters. Since the wired-OR glitch is a 
function of backplane length and loading, the wired-OR 
glitch filter can be optimized for a given backplane. 

The DS3884 is one of five current devices in the Future- 
bus+ Chip Set. The DS3883 BTL 9-Bit Data Transceiver 
and DS3886 BTL Latching Transceiver are used for the ad- 
dress/data, command, tag, and status lines. The DS3885 
Arbitration Transceiver has the competition logic for the 
AB<8:0> signal lines. The DS3875 Arbitration Controller 


Connection Diagrams 


3 
> 
© 
” 


31° BIGND 
30 B2 


29 B2GND 


DS3884VF 
POFP 
(Top View) 


26 BS 
27 BSGND 
26 BA 
25 84GND 
24 BS 


23 BSGND 


'B6 GND 21 Fa 


TL/F/10720-10 


supports all the required and optional modes for the Future- 


bus+ arbitration protocol. It is designed to be used in con- 
junction with the DS3884 and DS3885. 


Features | 

m@ Meets 1194.1 standard for backplane transceiver logic 

m Pinout is designed specifically for implementing a: 
Futurebus+ system 

@ Supports live insertion 

m Low skew 

@ Controlled rise/fall time 

@ Glitch free power-up/down protection 

@ Built-in bandgap reference provides very accurate 
thresholds 


~ & 44-pin PLCC 


m@ 44-pin PQFP saves board real-estate 


39 NC" 
38 BI 
37 BIGND 


36 B2 


DS3884V 
PLCC 
(Top View) 


34 BS 
33 B3GND 
32 B4 
31 B4GND 
30 BS 


29° BS GND 


86 GND 27 [3 


TL/F/10720-2 


Order Number DS3884V or DS3884VF 
See NS Package V44A or VF44B 
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35 B2GND 


yssesd 





DS3884 





Absolute Maximum Ratings (note 1) Recommended Operating © 
If Military/Aerospace specified devices are required, Conditions 
please contact the National Semiconductor Sales Min Max 
Office/Distributors for availability and specifications. Supply Voltage (Vcc) 45 55 
Supply Voltage 65V Bus Termination ox 
Control Input Voltage 6.5V ~ Voltage (V7) 2.06 O44 
_Driver Input and Receiver Output 6.5V Operating Free Air 


Note: At no time including power-up shall the control input, driver input or Temperature 0 +70: 
receiver output exceed Voc plus 1V. (See Note 2). ; 


Receiver Input and Driver Output 3V 
Power Dissipation at 70°C . 1.22W 
Storage Temperature Range —65°C to + 150°C 
Lead Temperature (Soldering, 4 sec.) 260°C 


DC Electrical Characteristics (notes 2,3 and 4) Ta = 0°C to +70°C, Voc = SV + 10% | 
Symbol | Parameter, =| ~=———S—SCCoondiitions, =| ~Min_ | Typ | Max | Units 
DRIVER AND CONTROL INPUT (Dn, DE, PS1 and PS2) Re ss 


Minimum inputHigh Voltage | 


Vin = 2.4V 
Vin = 0.5V 
IcLamp = —12mA mm 


Dn = 2.4V, DE = OV 
lo. = 80 mA , 


Dn = 0.5V, DE = OV, Bn = 0.75V 
Dn = 0.5V, DE = OV, Bn = 2.1V 


DE = 2.4V 


Voc = Maxor OV, Ign = 1 mA 2.4 3.4 


Voc = Max or OV, Ign = 10mA 
IcLamp = —12mA 


24 
Output Short Circuit Current —40 


Supply Current: Includes Vcc, | DE = 0.5V, All Dn = 2.4V 
QVoec and LI DE = 2.4V, AllBn = 2.1V 
DE = 2.4V 


DE = 0.5V, All An = 2.4V 


Note 1: Absolute Maximum Ratings are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply that the device should be 


operated at these limits. The table of “Electrical. Characteristics” provides conditions for actual device operation. : 


Note 2: All input and/or output pins shall not exceed Voc plus 1V and shall not exceed the absolute maximum rating at anytime, including power-up and power 
down. This prevents the ESD structure from being damaged due to excessive currents flowing from the input and/or output pins to QVoc and Voc. There is a diode 
between each input and/or output to Voc which is forward biased when incorrect sequencing is applied. Alternatively, a current limiting resistor can be used when 
pulling-up the inputs to prevent damage. The current into any input/output pin shall be no greater than 50 mA. Exception, LI and Bn pins do not have power 
sequencing requirements with respect to Voc and QVcc. Furthermore, the difference between Voc and QVcc should never be greater than 1V at any time 
including power-up. 

Note 3: All current into device pins are positive; all currents out of device pins are negative. All voltages are referenced to device ground unless otherwise 
specified. 

Note 4: All typical values are specified under these conditions: Voc = 5V and Ta = 25°C. 

Note 5: Referenced to appropriate signal ground. Do not exceed maximum power dissipation of package. 
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AC Electrical Characteristics T, = oc to +70°C, Vog = 5V + 10% (Note 6) 


Symbol Conditions [min | typ. | Max | Units 


DRIVER 


Dn to Bn DE = OV (Figures 7 and 2) 
Propagation Delay 


DE to Bn Enable Time | Dn = 3V (Figures 7 and 3) 
7 


Disable Time 


’ Transition Time-Rise/Fall (Figures 1 & 2) 
20% to 80% . 


Slew Rate is Calculated from Be 


1.3V to 1.8V 


Skew between Drivers in oo (Note 7) ; 
the Same Package 


DE = 3V (Figures 4 and 5) 
Propagation Delay . . 
Skew between Receivers (Note 7) _ 
in Same Package 


FILTERED RECEIVER ; 


Bn to FRn | PS1 = OV, PS2 = OV, DE = 3V 42 45 
Propagation Delay (Figures 4 and 5) 


PS1 = OV, PS2 = 3V, DE = 3V 
(Figures 4 and 5) 
PS1 = 3V, PS2 = OV, DE = 3V 
(Figures 4 and 5) 
PS1 = 3V, PS2 = 3V, DE = 3V 
(Figures 4 and 5) 


Bn to FRn DE = 3V 
Propagation Delay (Figures 4 and 5) (Note 8) 


PS1 = OV, PS2 = OV, DE = 3V 
(Figures 4 and 6) 
PS1 = OV, PS2 = 3V, DE = 3V 
(Figures 4 and 6) 
PS1 = 3V, PS2 = OV, DE = 3V 
(Figures 4 and 6) 
PS1 = 3V, PS2 = OV, DE = 3V 
(Figures 4 and 6) 


RECEIVER 


Glitch Rejection 


FILTERED RECEIVER TIMING REQUIREMENTS 


ts PSntoBn Set-Up Time (Figure 7) 400 | fe ns 


PARAMETERS NOT TESTED (Guaranteed by Design) 


(Note ) 
(Note 10) 


Note 6: Input waveforms shall have a rise/fall time of 3 ns. 


Note 7: tsxew is an absolute value, defined as differences seen in propagation delays between drivers or receivers in the same package with identical load 
conditions. 


Note 8: ten_y is independent of filter setting. 

Note 9: This parameter is tested during device characterization and is guaranteed by design. The parameter is tested using TDR techniques described in P1194 
BTL Backplane Design Guide. 

Note 10: This parameter is tested during device characterization and is guaranteed by design. The measurement revealed that the part will typically reject 1 ns 
pulse width. 
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y8sesd 


DS3884 


Pin all ate 


Number Input/ ia 
Pin Name Ee tue Description 


BI-B6 | | vo | BTL receiver Input and Driver Output. 


BI GND- oa Driver output ground reduces ound pence due to nighye current suptoning of driver 
Soar ae (Note 11) 


DE | 1 | Driver Enable Low 

Di-D6 a TTL driver input 

FR1-FR3 TTL TRI-STATE® filtered receiver output 

GND 4 Ground reference for switching circuits. (Note 11) 


Li 7 . Voc supply for live insertion. Boards that require live insertion should connect LI to the 
ah * "| five insertion pin on the connector. (Note 12) | 


NC No connect 
PS1, PS2 Pulse Width Selection pin determines glitch filter setting. (Note 13) 
R1-R6 . . TTL TRI-STATE receiver output 


REXT re en Fe External Resistor pin. External resistor is used for internal biasing of filter circuitry. The 
_ aes nc ey 6.0 kf resistor shall be connected between (REXT) = REXT and (GND) = GND. The 
resistor shall have a tolerance of 1% anda temperature coefficient of 100 ppm/*C or’ 
better. 


_QGND _.. i : _| Ground reference for receiver input banddas reference and non-switching circuits. (Note — 


11) 


Qcec .. . eA Vcc supply for bandgap reference and non-switching circuits. (Note 12) 


Voc ‘NA | Voc Supply for switching circuits. (Note 13) 


' Note 11: The multiplicity of grounds reduces the effective inductance of bonding wires and leads, which then reduces the noise caused by transients on the ground 


path. The various ground pins can be tied together provided that the externa! ground has low inductance (i.e., ground plane with power pins and many signal pins 
connect to the backplane ground). If the external ground floats considerably during transients, precautionary steps should be taken to prevent QGND from moving 
with reference to the backplane ground. The receiver threshold should have mes same ground reference as the signal coming from the backplane. A voltage offset 
between their grounds will degrade the noise margin. : 

Note 12: The same considerations for ground was used for Vc in reducing lead inductance (see Note 11:). sie and me should be tied together externally. If live 
insertion is not supported, the LI pin can be tied together with QVcc and Voc. | 


Note 13: See AC Characteristics for filter setting. 


Truth Table 7 + Glitch Filter Table 


X: High or Low Logic State 
Z: High Impedance State 

L: Low State 

H: High State 

L-H: Low to High Transition 
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Logic Diagram 


TL/F/10720-1 


Timing Waveforms 


TL/F/10720-3 TL/F/10720~4 


FIGURE 1. Driver Propagation Delay Set-Up FIGURE 2. Driver: Dn to Bn 


TL/F/10720-5 
FIGURE 3. Driver: DE to Bn 


Switch Position 
| teu | trae 
[_st_| Open | Close | 
RL =1ka 


TL/F/10720-7 


: TL/F/10720-6 is 
FIGURE 4. Recelver Propagation Delay Set-Up FIGURE >: Hegewer Bate FAN enone 


3V 
PS1,PS2 
ov 


Bn 
1.1V 


Wemeeeweewee = @ = = «= 


TL/F/10720-8 FIGURE 7. Receiver: PSn to Bn 


TL/F/10720-9 


FIGURE 6. Receiver: Ter 
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_0S3865 


4 


ZANational 


Semiconductor 





PRELIMINARY 


DS3885 BTL Arbitration Transceiver 


General Description = 


' The DS3885 Arbitration Transceiver conforms to IEEE P896 
: Futurebus+ specifications. The Arbitration transceiver: in- 


corporates the competition logic internally which simplifies 


‘ on board logic and reduces competition delays. 


_ and DS3886 BTL Latching Transceiver are used for the ad-: 


The DS3885 is one of five current devices in the Future- 
bus+ Chip Set. The DS3883 BTL 9-Bit Data Transceiver 


. dress/data, command, tag, and status lines. The DS3884 
_ Handshake Transceiver has a pulse width selectable wired- 
_ OR glitch filter and is used on the handshake lines. The 
_ DS3875 Arbitration Controller supports all the required and 


optional modes in the Futurebus+ arbitration protocol. It is 
designed to be used in cOnRnceon with the DS3884 and 
DS3885. 


Connection Diagrams 


r] 32 ABI GND 


DS3885VF 
POFP 
(Top View) 


r=] ‘27 ABS GND 
26 ABA GND 


.TL/F/10721-2 ; ; 
Order Number DS3885V or ps3essVF 


Features 

a Meets P1194.1 standard for Backplane transceiver logic 

m Pinout is designed specifically for implementing a 
Futurebus+ system 

m Supports Live Insertion 

m Low Skew 

@ Controlled rise/fall time 

m Glitch free power up/down protection 


_ @ Built-in bandgap reference provides very accurate 
““. thresholds 


m 44-pin PLCC 
m 44-pin PQFP saves board real-estate 


DS3885V 
PLCC 
(Top View) 


=] 29 ABS GND 


. * FL/F/10721-13 


See NS Package Number V44A or VF44B 
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Absolute Maximum Ratings (note 1) 


If Military/Aerospace specified devices are required, 
please contact the National Semiconductor Sales 


Storage Temperature Range 


65°C to + 150°C 
Lead Temperature 


S8sesd 





Office/Distributors for availability and specifications. _ (Soldering, 4 sec.) 260°C) 
Supply Voltage 6.5V 

Control Input Voltage 6.5V Recommended 

Driver Input and Receiver Output . 6.5V Operating Conditions’ 


Note: At no time including power-up shalt the control input, driver input or 
receiver output exceed Voc + 1V. (See Note 2) 


Receiver Input and Driver Output 3V 
Power Dissipation at 70°C . 1.22W - 


Min  .Max — Units 
Supply Voltage, Vcc 4.5 5.5 Vv 
Bus Termination Voltage (V7) .. 2.06 214 °° V> 

’ Operating Free Air Temperature © O28: 8 70 6 


DC Electrical Characteristics (Notes 2, 3 and 4) Ta = 0°C to +70°C, Veg = 5V £10% 


Symbol Conditions | Min | typ | Max |. units 


DRIVER AND CONTROL INPUT: (CNn CNP, CE, COMP, and RE) _ 


Maximum inputLowVoltage | © 


Input High Current Vin = 2.4V a 
Vin = 0.5V 
IcLAMP = —12mMA . 


| CNn = RE = 2.4V, LE = COMP = 0.5V 
lo. = 80 mA : 


| | 100 
ov] || 100 
| Receiver Input Threshold | COMP=TE=24v | 4.7 | 1.55 | 1.62 | 
Positive Clamp Voltage 
| Voo=Maxor0v,aBn=10ma_ | 29 | 3.9 | 5.0 | 

| Negative Clamp Voltage | Icramp=—12mA | 82 











Supply Current: includes Vcc, 
QVCC and LI 
Live Insertion Current 


Note 1: Absolute Maximum Ratings are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply that the device should be 
operated at these limits. The table of “Electrical Characteristics” provide conditions for actual device operation. ; 

Note 2: All input and/or output pins shall not exceed Veg + 1V and shall not exceed the absolute maximum rating at anytime, including power-up and power down. 
This prevents the ESD structure from being damaged due to excessive currents flowing from the input and/or output pins to QVcc and Vcc. There is a diode 
between each input and/or output to Voc which is forward biased when incorrect sequencing is applied. Alternatively, a current limiting resistor can be used when 
pulling-up the inputs to prevent damage. The current into any input/output pin shall be no greater than 50 mA. Exception, LI and Bn pins do not have power 
sequencing requirements with respect to Voc and QVcc. Futhermore, the difference between Voc and QVcc should never be greater than 1V at any time including 
power-up. 

Note 3: All currents into device pins are positive; all currents out of device pins are negative. All voltages are referenced to device ground unless otherwise 
specified. 

Note 4: All typicals are specified under these conditions: Voc = 5V and Ta = 25°C. 

Note 5: Referenced to appropriate signal ground. Do not exceed maximum power dissipation of package. 
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DS3885 


AC Electrical Characteristics 1, = 0°c to +70°C, Veg = 5V + 10% (Note 6) 


Symbol ee i ee Units 


DRIVER (Figures 7 and 2) 


LE to AB7 Propagation Delay 


Rise Time 20% to 80% 
Fall Time. 20% to 80% 


[oNntolE ___SotupTino | RE-av.0ouP-ov +t» | | 
cin _fedtine _{ FE =v Compo _| ¢ 1 
[tepusewen ____d| R= ov.comp=oy __|vs] |_| | 


ABn to CNn ' Prop. Delay RE = OV, COMP = LE = 3V 
. (Figures 4 and 5) 


REtoCNn Disable Time COMP = LE = 3V, ABn = 2.1V. 
Enable Time (Figures 6 and 7) 
Disable Time COMP = LE = 3V, ABn= 1.4V 
- | Enable Time (Figures 6 and 7) . 


ABO to AA Prop. Delay AB <7:1> = 1.1V . 
All Asserted Condition (Figures 4 and 8) pe 


ABOtoWIN Prop. Delay COMP = LE = OV, RE = 3V, 
Win Condition ~ | ON <7:0> = OV 
(Figures 4and 9) . AB<7:0> = 2.1V 


ABO to WIN Prop. Delay COMP = LE = 3V, RE = OV, 
Greater Than Condition - - | ON <7:1> = OV, CNO = 3V 
(Figures 4and9) AB<7:0> = 2.1V 


ABP to PER Prop. Delay COMP = LE = RE = 8V, 
Parity Error Condition | AB <7:1> = 1.1V, ABO = 2.1V 
(Figures 4 and 8) 





ABn to AB <n—1> Prop. Delay COMP = LE = OV, RE = 3V, 
. CNn = OV, CN <n-1> = 8V, 
CN <7:n+1> =0V 
‘(Figures 7 and 70) 


"| COMP to AB ~ Prop. Delay TE = ov, RE = CN7 = 8V Ts [6 | 12, 
(Figures 7 and 3) | 6 | 9 | 15 | 


AB7 to ABP Prop.Delay | COMP =[E=0V,RE=CNP=av,| | 30 | 49 | 


CN <7:0> =OV 
foowiowty | (fm fa 
PARAMETERS NOT TESTED (Guaranteed by Design) 


esis eae 
[NoiseRelection Noto) | 


Note 6: All input rise/fall times should be 3 ns. 

Note 7: This parameter is tested during device charaGientealion and is  ousrantood by design. The a is tested using TDR eoneiaues described in P1194.0 - 
BTL Backplane Design Guide. 

Note 8: This parameter} is tested auing device characterization and is mratioes by design. The measurement revealed that the part will typically reject 1 ns pulse 
width. - 
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Pin Description 


Number of Input/ 
Pin Name Output Description 


AA TTL—AIl asserted (A logic “0” Ingleales that all the competition ule 
are asserted.) 


AB<7:0> | 8s ~—v0 ss TL Futurebus+ wired-OR competition bits 


ABP BTL—Futurebus+ wired-OR competition parity bit _ 


S88eSd 


AB<7:0> and Driver output ground reduces ground bounce due to high current 
ABP GND switching of driver outputs (Note 9) 


CN<7:0> | TTL—Module competition bits 
TTL—Module competition parity bit 


TTL—Competition bit (A logic “0” indicates that the module will 
compete in the arbitration.) 


Ground reference for switching circuits. (Note 9) 


TTL—CNn latch enable (A logic “0” indicates that the CNn logic 
states are latched with corresponding parity bit. 


Voc supply for live insertion. Boards that require live insertion 
should connect LI to the live insertion a on the connector. 
(Note 10) 


No Connect 
TTL—ABn odd parity (A logic “0” indicates parity error) 
TTL—Receiver Enable (A logic “0” enables receivers) 


Ground reference for receiver input bandgap reference and non- 
switching circuits. (Note 9) 


Voc supply for bandgap reference and non-switching circuits. 
(Note 10) 


Voc supply for switching circuits. (Note 10) 


TTL—Win signal (active low). During competition, WIN indicates 

that the module has won the competition. For a module not 

participating in the competition, WIN indicates that the module has 

a number which is greater than winner’s number. 
Note 9: The multiplicity of grounds reduces the effective inductance of bonding wires and leads, which then reduces the noise caused by transients on the ground 
path. The various ground pins can be tied together provided that the external ground has low inductance. (i.e., Ground plane with power pins and many signal pins 
connected to the backplane ground.) If the external ground floats considerably during transients, precautionary steps should be taken to prevent QGND from 
moving with reference to the backplane ground. The receiver threshold should have the same ground reference as the signal coming from the backplane. A voltage 
offset between their grounds will degrade the noise margin. 
Note 10: The same considerations for ground was used for Vcc in reducing lead inductance. (See Note 9) QVcc and Vcc should be tied together externally. If live 
insertion is not supported, the LI pin can be tied together with QVcc and Voc. 
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DS3885 


Logic Diagrams 


M 


P 


R(LOAD) = 12.50 


DS3885 0 Vo 


C(LOAD) = 30 pF 





TL/F/10721 -3 
FIGURE 1. Driver Propagation Delay Set-up 


; = TL/F/10721-4 
FIGURE 2. Driver: LE to AB7, ts, tp, tow 


TL/F/10721-1 — 


TL/F/10721-5 


FIGURE 3. Driver: COMP to AB7- 
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Logic Diagrams (Continued) 


sssesd 


Switch Position 


3885 | 
si [open | tse 
[ses = 1kd 


C(LOAD) = sopF | Fl 


TL/F/10721-6 
FIGURE 4. Receiver Propagation Delay Set-up 


TUF 0721-7 _ 
FIGURE 5. Receiver: ABn to CNn 


Switch Position 


C(LOAD) = 50 pF 


TL/F/10721~-8 
: FIGURE 6. Receiver Enable/Disable Set-up : 


TL/F/10721-10 


TL/F/10721-9 
FIGURE 7. Recelver: RE to CNn .... FIGURE 8. ABO to AA 


AB<n> 
1 AB<7> 


Yo AB<n-1> Vou 
© ABP 


TL/F/10721-11 TL/F/10721-12 
FIGURE 9. ABO to WIN, ABP TO PER FIGURE 10. ABn to AB<n-1>, AB7 to ABP 
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DS3886 


ZA National 


Semiconductor 


PRELIMINARY 


DS3886 BTL 9-Bit Latching Data Transceiver 


General Description 
The DS3886 BTL 9-Bit Latching Transceiver is designed to 


conform to IEEE P1194.1 (BTL) as specified in IEEE P896.2 . 


(Futurebus + ). The DS3886 simplifies the implementation of 
all byte wide address/data with parity signals. It can also be 
used for the status, tag and command lines. 

The Driver has an edge-triggered latch which can be by- 
passed during fall-through mode. The receiver has a trans- 
parent latch. , 

The DS3886 is one of five current devices in the 
Futurebus+ Chip Set. The DS3883 BTL 9-Bit Data Trans- 
ceiver is an option to the DS3886 without 'the latches. The 
DS3884 Handshake Transceiver has pulse width selectable 


wired-OR glitch filters. The DS3885 Arbitration Transceiver | 


has the competition logic for the AB<8:0> signal lines. The 
DS3875 Arbitration Controller supports all the required and 
optional modes for the Futurebus+ arbitration protocol. It is 
designed to be used in conjunction with the DS3884 and 
DS3885. 


Connection Diagrams 


i] 32 B2 GND 


DS3886VF - 
~ -PQFP. 
(Top View) 


L:] 27 B4 GND 


TL/F/10722-12 


Order Number DS3886V or DS3886VF 


Features 

m Meets P1194.1 standard for Backplane transceiver logic 

m Pinout is designed specifically for implementing a 
Futurebus+ system 

m Supports live insertion 

m Low skew 

@ Controlled rise/fall time 

™ Glitch free power-up/down protection 

™ Built-in bandgap reference provides very accurate 
thresholds 

m 44-pin PLCC 

@ 44-pin PQFP reduces board real-estate 

m@ On chip latches 


DS3886V 
~~ PLOC 
(Top View) 


TL/F/10722=13 


See NS Package V44A or VF44B. 
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Absolute Maximum Ratings (note 1) 


If Military/Aerospace specified devices are required, 
please contact the National Semiconductor Sales 


Storage Temperature Range 
Lead Temperature 


—65°C to + 150°C 


988€Sd 





Office/Distributors for availability and specifications. 
Supply Voltage 6.5V 
Control Input Voltage 6.5V Recommended 

Driver Input and Receiver Output 6.5V Operating Conditions 


Note: At no time including power-up shall the control input, driver input or Min Max 
receiver output exceed Voc + 1V. (See note 2.) 


(Soldering, 4 seconds) 260°C 


Units 
Supply Voltage, Voc 4.5 5.5 Vv 
Bus Termination Voltage (V7) 2.06 2.14 V 
Operating Free Air Temperature oO = 70 °C 


Receiver Input and Driver Output 3V 
Power Dissipation at 70°C 1.22W 


DC Electrical Characteristics (Notes 2, 3 and 4) Ta = O°C to +70°C, Voc = BV +10% 


symbol | __Parameter_ | Gonaitions, =| win | Typ | Max | Units 
DRIVER AND CONTROL INPUT (CD, T/R, An, ACLK, LE, and RBYP) , 
| MinimuminputHighVotage | ft | 
| Maximum inputLowVotage | | 
[InputHigh Curent | v= eave | 
FAnCD,T/Ainputs | vw= ogy || = 100 | 
| InputDiode Clamp Voltage | Ieamp=-12ma_ TT = 12 | 


ae orn 
(Note 5) < = 80 mA 

| Output Low Bus Curent | An=O8V,T/A=24v.en=a78v | |_ 8 | —260 | 

OutputHigh Bus Current = | An=0.5V,T/R=24v.en=21v | |__| 100 

An = 0.5V, T/R = 2.4V,Bn=21V,Voc=ov] | 5 | 100 | 

Positive Clamp Voltage emanated ana 


|Voo=Maxorov.en=10ma | 29 | 39 | 50 _ 
[ea 


| Voltage Output High | Output High ; |.24 | 32 | | 
Petercumin — [i=astinn aig em [Pose 

[T/A =CD=O8V,En=21Vlon=ema | | 0.95 | 04 | 
[Supt sronCreurcurent | an sawTR=ep=osy | 40 | 70 | 10 


a rs ee 
Trit=avmmmenr | ts | 6 


Note 1: Absolute Maximum Ratings are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply that the device should be 
operated at these limits. The table of “Electrical Characteristics” provides conditions for actual device operation. 

Note 2: All input and/or output pins shall not exceed Vcc + 1 and shall not exceed the absolute maximum rating at anytime, including power-up and power down... 
This prevents the ESD structure from being damaged due to excessive currents flowing from the input and/or output pins to QVcc and Voc. There is a diode 
between each input and/or output to Voc which is forward biased when incorrect sequencing is applied. Alternatively, a current limiting resistor can be used when 
pulling-up the inputs to prevent damage. The current into any input/output pin shall be no greater than 50 mA. Exception, LI and Bn pins do not have power 
sequencing requirements with respect to Voc and QVcc. Furthermore, the difference between Vcc and QVcc should never be greater than 1V at any time 
including power-up. 

Note 3: All currents into device pins are positive; afl currents out of device pins are negative. All voltages are referenced to device ground unless otherwise 
specified. 

Note 4: All typical values are specified under these conditions: Voc = 5V and Ta = 25°C, unless otherwise stated. 

Note 5: Referenced to appropriate signal ground. Do not exceed maximum power dissipation of package. 
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Negative Clamp Voltage IcLAMP = —12mA 


Live Insertion Current 





DS3886 


AC Electrical Characteristics 1, = 0°c to +70°C, Vog = 5V + 10% (Note 6) 


| Conditions 
‘| DRIVER eine. 4 


tPHL An to Bn Propagation Delay CD = OV, T/R = RBYP = 3V 
tPLH Fall-Through Mode = .:".: ‘|. (Figures 7 and 2) ; 


tPHL ACLK to Bn Propagation Delay| CD = RBYP = OV, T/R = 3V 
tei . Latch Mode (Figures 1 and 4) 


OD = RBYP = ov, T/A = ey 
(ures 1 end 4) 


SR CD = RBYP = OV, T/R = 3V 
_ from 1.3V to 1.8V : (Figures 7 and 4) : 
ia 
| DRIVER TIMING REQUIREMENTS (Figure 4) ; 
3 | CD = RBYP = OV, T/R = 3V 


(=) 


15 


Oo 


a/a —afa 3 a fo a }/oa]- 
Ly) oO tlt (eed 


{ 
1 


ACLK Pulse Width CD = RBYP = OV, T/R = 3V 


| RECEIVER . . 


tpHL Bn to An Propagation Delay CD = T/R = OV, LE = 3V | 
te Bypass Mode (Figures 5 and 6) : 


tpHL LE to An Propagation Delay |. CD = T/R = OV 

t Latch Mode (Figures 5 and 7) 

PLH 

tpLz - «|. CDtoAn Disable Time Bn = 2.1V, T/R = OV (Figures 8 and 9) 


tezL Enable Time 


tpHz Disable Time Bn = 1.1V, T/R = OV (Figures 8 and 9) 4 


ie) 


tpZH Enable Time 


~ tpiz T/R to An Disable Time CD = OV (Figures 10 and 717) 
tpzL 1 Enable Time |° oy 
tpHz Disable Time Bn = 1.1V, CD = OV (Figures 8 and 9) 


tPZH Enable Time - - a 4. 


Oo 


4 
4 


9 
a 


RECEIVER TIMING REQUIREMENTS (Figure 7) : 


PARAMETERS NOT TESTED (GUARANTEED BY DESIGN) 2 Day 


ee 8 
— 
ea 
——s 


Sees 
ae 
fee 
La) 
pea 


Coutput Capacitance at Bn | | (Note 8) . 
Noise Rejection « - ‘(Note 9) 


Note 6: Input waveforms shall have a rise/fall time of 3 ns. 7s 


Note 7: tskew is an absolute value, defined as differences seen in propagation delays between drivers or receivers in the same package with identical load 
conditions. : 

Note 8: This parameter is tested during device characterization and is guaranteed by design. The parameter is tested using TDR techniques described in P1194.0 
BTL Backplane Design Guide. 


Note 9: This parameter is tested during device characterization and is guaranteed by design. The measurement revealed that the part will typically reject 1 ns pulse 
width. : ees : 
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on 


Number 
of Pins 


Pin Descript 


988€Sd 


Input/ 
Output 


1/0 TTL TRI-STATE® receiver output and driver input - 
Clock input for latch 


Pin Name 


Description 


AO-A8 

ACLK 

BO-B8 
BOGND-B8GND 


BTL receiver input and driver output 


= 
> 


Driver output ground reduces ground bounce due to high current switching of driver 
outputs. (Note 10) ; : 


Chip Disable —_ 
Ground reference for switching circuits. (Note 10) 
Latch Enable © 


Voc supply for live insertion. Boards that require live insertion should connect LI to 
the live insertion pin on the connector. (Note 11) 


cD 


LE 
Ll 


NC 
QGND 


za 


No Connect 


a 


Ground reference for receiver input bandgap reference and non-switching circuits. 
(Note 10) ase eg alt 


Vcc supply for bandgap reference and non-switching circuits. (Note 11) 


= 


= = 


QVcc 

RBYP 
T/R 
Voc 

Note 10. The Multiplicity of grounds reduces the effective inductance of bonding wires and leads, which then reduces the noise caused by transients on the ground 

_ path. The various ground pins can be tied together provided that ‘the external ground has low inductance (i.e., ground plane with power pins and many signal pins 

‘\ connected to the backplane ground). If the external ground floats considerably during transients, precautionary steps should be taken to prevent QGND from 


‘ moving with reference to the backplane ground. The receiver threshold should have the same ground reference as the signa! coming from the backplane. A voltage 
offset between their grounds will degrade the noise margin. ~ 5 : 


Note 11; The same consideration for ground was used for Voc in reducing lead inductance (see Note: 10). QVcc and Vcc should be tied together externally. If live 
insertion is not supported, the LI pin can be tied together with QVcc and Voc. . ai 


Register bypass enable: 
Transmit/Receive—Transmit (An to Bn, AcLk to Bn) Receive (Bn to An, LE to An) 


= 
> 


Voc supply for switching circuits. (Note 11) 


sf 


Truth Table . 





J Ack | An | Bn | 
Ea ee ee 
x tale 

7 





X = High or low logic state 
Z = High impedance state 
L = Lowstate - 
H = High state 

L-H = Low to high transition 
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— pS3886 


Logic Diagram 


7 


epee _ 
: Tele EO” : 
° rai DEO “ 
Cel EO” : 
. a sa Se 
i aT 3 


rai DEO | 
=i eee 7 
ee 


ale 


TL/F/10722-1 


. WwW 
vy, An, T/R ; 
wv---- 


a TL/F/10722 
FIGURE 2. Driver: An to Bn, T/R to Bn 











Test Circuit and Timing Waveforms (Continued) 


3V 
An 
OV 


3V 
OV 


| You 
TL/F/10722-5 Yo . Bn 
Vou 
TL/F/10722-6 
FIGURES PaverCP en FIGURE 4. Driver: ACLK to Bn, ts, th, tow 


Switch Position 
| st_| open | close _| 





C, = S0pF | R, = 1ko 


= : __TL/F/10722-7 
FIGURE 5. Receiver Propagation Delay Set-up 


TL/F/10722-8 1.5V 


TL/F/10722-9 
FIGURE 6. Receiver: Bn to An FIGURE 7. Receiver: LE to An, ts, ty, tow 


Switch Position 


TL/F/10722-10 
FIGURE 8. Receiver Enable/Disable Set-up 


1.5V 
TL/F/10722-11 


FIGURE 9. Receiver: CD to An, T/R to An 
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Test Circuit and Timing Waveforms (Continued) 


DS3886 


i TL/F/10722-14 
FIGURE 10. T/R to An, T/R to Bn 


TL/F/10722-15 


FIGURE 11. tpy. (T/R to Bn), tpz, (T/R to An) 
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Za National 


Semiconductor 


DS3862 Octal High Speed Trapezoidal Bus Transceiver 


General Description 


The DS3862 is an octal high speed schottky bus transceiver 
intended for use with terminated 1202 impedance lines. It is 
specifically designed to reduce noise in unbalanced trans- 
mission systems. The open collector drivers generate pre- 
cise trapezoidal waveforms with rise and fall times of 9 ns 
(typical), which are relatively independent of capacitive 
loading conditions on the outputs. This reduces noise cou- 
pling to the adjacent lines without any appreciable impact 
on the maximum data rate obtainable with high speed bus 
transceivers. In addition, the receivers use a low pass filter 
in conjunction with a high speed comparator, to further en- 
hance the noise immunity. Tightly controlled threshold lev- 
els on the receiver provide equal rejection to both negative 
and positive going noise pulses on the bus. 

The external termination is intended to be a 1802 resistor 
from the bus to 5V logic supply, together with a 3902 resis- 
tor from the bus to ground. The bus can be terminated at 
one or both ends. , 


Logic and Connection Diagram 


DS3862 


(cD) 
CHIP DISABLE 


Features 

m Guaranteed A.C. specifications on noise immunity and 
propagation delay over the specified temperature and 
supply voltage range 

m Temperature insensitive receiver thresholds track bus 
logic level and respond symmetrically to positive and 
negative going pulses 

™ Trapezoidal bus waveforms reduce noise coupling to 
adjacent lines 

m Open collector driver output allows wire-or connection 

g Advanced low power schottky technology — 

™ Glitch free. power up/down protection on driver and re- 
ceiver outputs . 

m= TTL compatible driver and control inputs; and receiver 
outputs , 

g Control logic is the same as the DS3896 


Order Number DS3862J or DS3862N 
See NS Package Number J20A or 
N20A 


TL/F/8539~1 
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DS3862 


Absolute Maximum Ratings (note 1) Recommended Operating 


If Military/Aerospace specified devices are required, Conditions 
please contact the National Semiconductor Sales 
Office/Distributors for availability and specifications. Supply Voltage, Voc 4.75 505 


Supply Voltage. ee * 6V Operating Free Air Temperature 0 ‘70° 
Control Input Voltage 5.5V o4 
Driver Input and Receiver Output 5.5V 
Receiver Input and Driver Output _ §.5V 
‘Power Dissipation 1400 mW 
Storage Temperature Range —65°C to + 150°C 
Lead Temperature (Soldering, 4seconds) | - 260°C 


Electrical Characteristics oc <1, < 70°C, 4.75V < Voc < 5.25V unless otherwise specified (Notes 2 and 3) 


symbol | ___—sParameter_ =| ~——SConditions, | Min | Typ | Max | Units 
Driver and Control Inputs: souls 
| Logical"t”inputVottage | 
| Logical“o" nputvotage | 
Logical “1” Input Current 
Logical “0” input Current 
CD & T/R Logical “0” Input Current 


An = T/R = 2V, Ibus = 100 mA 
Logical “1” Bus Current An = 0.8V,Bn = 4V, Voc = 5.25Vandov| | 10. | 100 | 
Logical “o” Bus Current 





Logical “1” Output Voltage Bn = 0.9V, lon = — 400nA 


Logical ‘‘0” Output Voltage Bn = 4V, lo) = 16mA 


Note 1: ‘Absolute Maximum Ratings” are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply that device should be 
operated at these limits. The table of “Electrical Characteristics” provide conditions for actual device operation. 

Note 2: All currents into device pins are positive; all currents out of device pins are negative. All voltages are referenced to device ground unless otherwise 
specified. 7 

Note 3: All typicals are given for Vcc = 5V and Ta = 25°C. 
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Switching Characteristics orc < T, < 70°C, 4.75V < Vec < 5.25V unless otherwise specified 


Symbol Conditions | win | tye | Max | units 


Driver: 


ee 

toHL [ese A eo 

eee ee 
aaa 


toLHT T/R to Bn VCl = An, VC = 5V, (Figure 2) 


ae CD = 0.8V, RC = 390, CL = 30pF 
AL1 = 91, RL2 = 200M, VL = 5V 
ta Driver Output Rise Time | CD =0.8V,T/R=2V,VL=5V (Figurot) | 4 | 9 | 20 | 
Driver Output Fall Time Rowe 2 
tRLH 


eee ee eee 
tRHL | ts [| 
z= 


e98ESd 


Receiver: 


taLzc CD to An n= 2.0V, T/R = 0.8V, CL = 5 pF 
RL1 = 3909, RL2 = NC, VL = 5V (Figure 4) 


taz7Lc Bn = 2.0V, T/R = 0.8V, CL = 30 pF 

RL1 = 3900, AL2 = 1.6K, VL = 5V (Figure 4) 
tRHZC Bn = 0.8V, T/R = 0.8V, VL = OV, 

RL1 = 3909, RL2 = NC, CL = 5 pF(Figure 4) 
tRZHC Bn = 0.8V, T/R = 0.8V, VL = OV, 

RL1 = NC, RL2= 1.6K, CL = 30 pF (Figure 4) 


tRLZT T/R to An VC! = Bn, VC = 3.4V, RC = 390. 
CD = 0.8V, VL = 5V, RL1 = 3900, 
. RL2 = NC, CL = 5pF (Figure 2) 
tRZLT VCI = Bn, VC = 3.4V, RC = 390, 
: CD = 0.8V, VL = 5V, AL1 = 3900, 
RL2 = 1.6K, CL = 30pF (Figure 2) 


tRHZT VCI = Bn, VC = OV, RC = 390, 

CD = 0.8V, VL = OV, RL1 = 3900, 

RL2 = NC, CL = 5pF (Figure 2) 
tRZHT VCI = Bn, VC = OV, RC = 390, 

CD = 0.8V, VL = OV, RL1 = NC 

RL2 = 1.6K, CL = 30 pF (Figure 2) 


tnR Receiver Noise Rejection , (Figure 5) ° 12 
Pulse Width 


Note: NC means open 
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DS3862 


Switching Waveforms 


(Co) 


30 pF 
(INCLUDES JIG CAPACITANCE) 


‘TL/F/8539-2 


Note: t- = t; < 5ns from 10% to 90% : 
FIGURE 1. Driver Propagation Delays 


. . _ wv 

x : WA) 
Vo (Bn) 
Vo (An) 


Vo (An) 


C, te 
(INCLUDES JIG CAPACITANCE) 


TL/F/8539-3 


Note: t; = t < 5 ns from 10% to 90% = 
FIGURE 2. Propagation Delay From T/R Pin to An or Bn. 
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Switching Waveforms (Continued) 


c98eSd 


30 pF 
(INCLUDES JIG CAPACITANCE) 


TL/F/8539~4 


Note: ta = te < 10 ns from 10% to 90% 
FIGURE 3. Receiver Propagation Delays 


R,2 C 
(INCLUDES JIG CAPACITANCE) 


TL/F/8539-5 


Note: t; = t; < 5ns from 10% to 90% 
FIGURE 4. Propagation Delay From CD Pin to An 


‘ 
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DS3862 


Switching Waveforms (continueg) 


Note: t, = t} = 2 ns from 10% to 90% 


FIGURE 5. Recelver Nolse Immunity: No Response at Output Input Waveform. 


Typical Application 


5V 


0S3862 


° 
6 
4 
t 
(] 
i] 
‘ 
i] 
t) 
t] 
e 


1200 UNIFIED DATA BUS 
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pewcecucccuse 


30 pF 


(INCLUDES JIG CAPACITANCE) 


~” ps3862 


TL/F/8539-6 


TL/F/8539-7 





ZA National 


Semiconductor 


DS3890 BTL Octal Trapezoidal Driver 
DS3892 BTL Octal TRI-STATE® Receiver 
DS3898 BTL Octal Trapezoidal Repeater 


General Description 


The DS3890, DS3892 and DS3898 are designed specifical- 
ly to overcome problems associated with driving densely 
populated backplanes. These products provide significant 
improvement in both speed and data integrity in comparison 
to conventional bus drivers and receivers. Their low output 
capacitance, low voltage swing and noise immunity features 
make them ideal for driving low impedance busses with min- 
imum power dissipation. 

The DS3890 and DS3898 feature open collector outputs 
that generate precise trapezoidal waveforms with typical 
rise and fall times of 6 ns which are relatively independent 
of capacitive loading conditions. These controlled output 
characteristics significantly reduce noise coupling to adja- 
cent lines. 

To minimize bus loading, the DS3890 and DS3898 also fea- 
ture a schottky diode in series with the open collector out- 
puts that isolates the driver output capacitance in the dis- 
abled state. With this type of configuration the output low 


Logic and Connection Diagrams 
DS3890 Octal Trapezoidal Driver 


eee OF 


TL/F/8700-1 


DS3892 Octal TRI-STATE Receiver 


voltage is typically ‘1V”. The output high level is intended to 
be 2 volts. This is achieved by terminating the bus with a pull 
up resistor. Both devices can drive an equivalent DC load of 
18.52 (or greater) in the defined configuration. 


(General Description to be continued). 


Features 

m Driver output capacitance less than 5 pF 

m 1 volt bus signal reduces power consumption 

m™ Trapezoidal driver waveforms (t,, ts, typically 6 ns) re- 
duces noise coupling to adjacent lines 

m Precise receiver threshold track the bus logic high level 
to maximize noise immunity in both logic high ahd low 
states 

m Open collector driver output allows wire-or connection 

m Advanced low power schottky technology 

m Glitch free power up/down protection 

mg TTL compatible driver and-control inputs and receiver 
output : 

m BTL compatible 


DS3898 Octal Trapezoidal Repeater 


Sate 


rYYY YY 
a 
28 


ye 





i 


TL/F/8700-2 TL/F/8700-3 


Order Numbers DS3890J, N, DS3892J, N or DS3898J, N 
See NS Package Number J20A or N20A 
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DS3890/ DS3892/ DS3898 


Absolute Maximum Ratings (ote 1) 


If Military/Aerospace specified devices are required, 
please contact the National Semiconductor Sales 
Office/Distributors for availability and specifications. 
Supply Voltage 

Control Input Voltage 

Driver Input and Receiver Output 


Receiver Input and Driver Output = 2.5V ° 


Storage Temperature Range 2. =65°C to +165°C* 


Lead Temperature (Soldering, 4 sec.) 260°C 


Recommended Operating _ 
Conditions a St a 
Min ~ Max 
Supply Voltage 4,75 5.25 
Temperature (Ta) O.-'. 7 


DS3890 Electrical Characteristics (Notes 2 and 3) 


DRIVER AND CONTROL INPUTS 


Symbol 
Vin les octagon 
Vi eee eel 
hn 
hy Dis 
DRIVER OUTPUT ; 


Voc=Max Vin=2.4V 


DS3892 Electrical Characteristics (Notes 2 and 3) 


CONTROL INPUTS 


"Conditions x ce 
ss .Voc=Max Vin=0.4V . 
, ~Vec=Max Vin=2.4V 
ao Voc= Max Vin=5.25V- 
Vec=Min |lij=—-12mA 
Vec=Min IoLp=16mA 


VoL. 


Vou : Voc=Min lIox=—400 pA 


RECEIVER 


VtH Rec Voc=5V 
ly Rec ‘Véc=Max Vin=2V 
;Rec . . Voc=0V Vin=2V 


los ° Voc= Max Vout=0V ak 
ly. Rec Voc=Max Vin=0.75V 


Icc Low = 
Es “>” Moc= Max 





Ioc High 
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DS3898 Electrical Characteristics (Notes 2 and 3) 
CONTROL INPUTS 


| Voo=Max Vn=oav | | 180 | 400 
| Voo=Max vwe2av | Tt 
| Voo=Max viws25v | | Tt 
| Voo=Min_iw=-tama | | 09 |= 185 


[eo=0v vw=2v 
To Voo= Wax vv=076v 


868ESA/Z268ESG/068ESA 


Voc=Min RL =18.50 — 


Voc= Max 
Ioc High 


Note 1: “Absolute Maximum Ratings” are those values beyond which the safety of the device cannot be guaranteed. They are not meant to imply that the device 
should be operated at these limits. The Table of “Electrical Characteristics” provides conditions for actual device operation. 


Note 2: All currents into device pins are shown as positive values; all currents out of the device are shown as negative; all voltages are referenced to ground unless 
otherwise specified. All values shown as max or min are classified on absolute value basis and apply to the full operating temperature and Vcc range. 


Note 3: All typical values are Voc =5V, Ta= 25°C. . ay 





DS3890 Switching Characteristics (Figure 1) 


(0°C< Ta<70°C, 4.75V<Voc<5.25V unless otherwise specified) * 


Anto Bn 


Dis to Bn 


Bn rise and fall time 





DS3892 Switching Characteristics (Figures 2 sina 4) 


Symbol Conditions | min | typ | Max 
Ta rere eet ee a eet 


TpHL 
Taiz 


Taz Dis to An 
TdHz 


Taz [aie Ra ae ER are 
TNR __|___Receivernoisereiection | 3 | es | 
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DS3890/DS3892/DS3898 


DS3898 Switching Characteristics (Figures 4 and 5) 


Symbol Conditions 


Tat Bito BOn 
TdHt 
Tat Dis to BOn 
TdHL 


Tr & Ty - ‘Bnrise and fall time 
TNR 


General Descriptions (continued) 


The DS3892 and DS3898 receiver inputs incorporate a low 
pass filter in conjunction with high speed comparator to fur- 
ther enhance the noise immunity. Both devices provide 
equal rejection to both positive and negative noise pulses 
(typically 6 ns) on the bus. 

The DS3890 features TTL compatible inputs while both the 
DS3892 and DS3898 inputs are BTL compatible. The con- 
trol inputs on all devices are TTL compatible. 

BTL “Backplane Transceiver Logic” is a new logic signaling 
method developed by IEEE P896 Future Bus Stan- 


AC Switching Waveforms 


DISABLE 


DS3890 


Note: tg=tF<10 ns from 10% to 90% 


dards Committee. This standard was adopted to enhance 
the performance of Backplane Busses. BTL compatible bus 
interface circuits feature low capacitance drivers to mini- 
mize bus loading, a 1V nominal signal swing for reduced 
power consumption and receivers with precision thresholds 
for maximum noise immunity. This new standard overcomes 
some of the fundamental limitations of TTL bus transceivers 
in heavily loaded backplane bus applications. Devices de- 
signed to this standard provide significant improvements in 
switching speed and data integrity. 


TL/F/8700-4 


Vo 


30pF 2. ne 
(INCLUDES JIG CAPACITANCE) 


TL/F/8700-5 


FIGURE 1 
Driver Propagation Delays 





AC Switching Waveforms (Continueg) 
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aieieieexe (INCLUDES JIG CAPACITANCE) 


Note: tga=te<10 ns from 10% to 90% TL/F/8700-7 


FIGURE 2. Receiver Propagation Delays 


Vi (DISABLE) 
| . TL/F/8700-8 


Vo 


C “ 
(INCLUDES JIG CAPACITANCE) ? | (INCLUDES JIG CAPACITANCE) 


TL/F/8700-14 Note: ta = te < 5ns from 10% to 90% TL/F/8700-9 


tozH 


DS3892 





CL CL 
| (INCLUDES JIG CAPACITANCE) | (INCLUDES JIG CAPACITANCE) 


TL/F/8700-15 , TL/F/8700-16 
FIGURE 3. Propagation Delay from Disable Pin to An 


Note: tg = tr < 5 ns from 10% to 90% 
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DS3890/DS3892/DS3898 


AC Switching Waveforms (Continued) 


BUS LOGIC 
LOW LEVEL 


| (INCLUDES JIG CAPACITANCE) 


Note: ta = te < 2 ns from 10% to 90% 
FIGURE 4 


Receiver Noise Immunity: 
“No Response at Output” Input Waveforms 


DISABLE 


BI OR DISABLE OV 


DS3898 Vo 
30 pF 
(INCLUDES JIG CAPACITANCE) 


Note: ta = tz < 10 ns from 10% to 90% 
FIGURE 5 


Repeater Propagation Delays 
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BUS LOGIC 
2V HIGH LEVEL 


TL/F/8700-10 


TL/F/8700-11 


. TL/F/8700-12 


TL/F/8700~13 











ZA National 


Semiconductor 


DS3893A BTL TURBOTRANSCEIVER™ 


General Description 


The TURBOTRANSCEIVER is designed for use in very high 
speed bus systems. The bus terminal characteristics of the 
TURBOTRANSCEIVER are referred to as “Backplane 
Transceiver Logic” (BTL). BTL is a new logic signaling stan- 


dard that has been developed to enhance the performance - 


of backplane buses. BTL compatible transceivers feature 
low output capacitance drivers to minimize bus loading, a 
1V nominal signal swing for reduced power consumption 
and receivers with precision thresholds for maximum noise 
immunity. This new standard eliminates the settling time de- 
lays, that severely limit the TTL bus performance, to provide 
significantly higher bus transfer rates. 


The TURBOTRANSCEIVER is compatible with the require- 
ments of the proposed IEEE 896 Futurebus draft standard. 
It is similar to the DS3896/97 BTL TRAPEZOIDAL Trans- 
ceivers but the trapezoidal feature has been removed to 
improve the propagation delay. A stripline backplane is 
therefore required to reduce the crosstalk induced by the 
‘faster rise and fall times. This device can drive a 1029 load 
with a typical propagation delay of 3.5 ns for the driver and 
5 ns for the receiver. 


When multiple devices are used to drive a parallel bus, the 


driver enables can be tied together and used as a common - 
’ Built-in bandgap reference provides accurate receiver 


control line to get on and off the bus. The driver enable 
delay is designed to be the same as the driver propagation 
delay in order to provide maximum speed in this configura- 
tion. The low input current on the enable pin eases the drive 
required for the common control line. 


Connection and Logic Diagram 


Order Number DS3893AV 


The bus driver is an open collector NPN with a Schottky 
diode in series to isolate the transistor output capacitance 
from the bus when the driver is in the inactive state. The 
active output low voltage is typically 1V. The bus is intended 
to be operated with termination resistors (selected to match 
the bus impedance) to 2.1V at both ends. Each of the resis- 
tors can be as low as 200. 


Features 

uw Fast single ended transceiver (typical driver enable and 
receiver propagation delays are 3.5 ns andSns) 

m Backplane Transceiver Logic (BTL) levels (1V logic 
swing) 

m@ Less than 5 pF bus-port capacitance 


m Drives densely loaded backplanes with equivalent load 


impedances down to 102. ee 

m 4 transceivers in 20 pin PCC package 

@ Specially designed for stripline backplanes 

m Separate bus ground returns for each driver to minimize 
ground noise Bes rail 

High impedance, MOS and TTL compatible inputs 

= TRI-STATE® control for receiver outputs 


threshold 
m Glitch free power up/down protection on all outputs 
m Oxide isolated bipolar technology 


BUS 


TL/F/8698~-1 


See NS Package Number V20A 
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DS3893A 


Absolute Maximum Ratings (note 1) 


If Military/Aerospace specified devices are required, 
please contact the National Semiconductor Sales 
Office/Distributors for availability and specifications. 


Supply Voltage 6.5V 
Control Input Voltage 5.5V 
Driver Input and Receiver Output 5.5V 
Driver Output Receiver Input Clamp Current +15mA 
Power Dissipation at 70°C 900 mw 


Electrical —— (Notes 2, 3 and 4) Ta = 0 to +70°C, Voc = 


Storage Temperature Range —65°C to + 150°C 
Lead Temperature (Soldering, 3 sec.) 260°C 


Recommended Operating 
Conditions 

Min 
Supply Voltage, Vcc 4.5 
Bus Termination Voltage (V7) 2.0 
Operating Free Air Temperature 0 


5V +10% 


Symbol a Units 


DRIVER AND CONTROL INPUT: (DE, RE, Dn) 


Input High Voltage eae 


Input Low Voltage 


input Leckege Curent | b&=FE=on=Vog | —S«d «id= 
input tig Curent) DE=RE~on=2ev—s| Si Sid 
[Lon input Low Curent | On = 08,0 =Vog= wax | |__| =200 | 
[OE inputLow Curent | DE= 08V,Dn=Voo= Max |_| 500" 
RE inputuow Curent | RE = 08V,Vog=Max | | +d 100 | 
[rowbedeanpvtage —[lmmp= —"ema_— Tt 


DRIVER OUTPUT/RECEIVER INPUT: (Bn) . 
. Output Low Bus Voltage 


Dn = DE = Vip (Figure 2) 
Rr = 109, Vr = 2.2V . 


Dn = DE = Vip (Figure 2) 
Rr = 18.59, V7 = 2.14 


Output Bus Current (Power On) Dn = DE = 0.8V, Vcc = Max 
Bn = 0.75V 

Output Bus Current (Power Off) Dn = DE = 0.8V, Vcc = OV 
Bn = 1.2V 


Driver Output Positive Clamp Voc = Maxor OV, Bn = 1mA a 
Voo=Maxorov,.Bn=10mA | || 82 


Output High Bus Voltage -». 1 Voc = Max, Dn = 0.8V (Figure 2) 
Vr = 2.0V, Rr = 109 


Receiverinput Threshold... | | te 85 | 1.62 


RECEIVER OUTPUT: (Rn) 


Voltage Output High Bn =1.2V,ln=—3mA,RE=o8v | 25v | | | 
Voltage Output Low | Bn=2V,lj=6mA,RE=08v | | 035 | o5 | 


TRI-STATE Leakage 


A 


| Vo=O5VRE=2v | | | = 20 


Output Short Circuit Current 
(Note 5) 


Bn = 1.2V, Vo = OV 
RE = 0.8V, Voc = Max . 


Supply Current ‘Dn = DE = RE = Vin, Voc = Max 


—120 


a 





Note 1: “Absolute maximum ratings” are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply that the device should be 
operated at these limits. The table of “Electrical Characteristics” provide conditions for actual device operation. 


Note 2: All currents into device pins are positive; all currents out of device pins are OSes; All voltages are referenced to device ground unless otherwise 


specified. 
Note 3: All typicals are given for Voc = 5V and Ta = “25°C. 


Note 4: Unused inputs should not be left floating. Tie unused inputs to either Voc or GND thru a resistor. 


Note 5: Only one output at a time should be shorted. 





Switching Characteristics 1, = 0 to +70°C, Voc = 5V + 10% 


symbol Conditions | Min | typ | Max | Units 


DRIVER: (Figures 3 and 6) 


ve6sesd 


Vr = 2V, Rr = 100, CL = 30 pF, Dn = 3V 


Vy = 2V,Rr = 109,C, = 30pF,Dn = 3V | 1 


CL = 50 pF, RE = DE = 0.3V, S3 Closed 
C_ = 50 pF, RE = DE = 0.3V, S3 Open 





C. = 50 pF, R, = 500, DE = 0.3V 
S2QOpen Bn = 2V 


C_ = 50 pF, RL = 500, DE = 0.3V 
$1 Open Bn=1V 


C, = 50 pF, Ri = 500, DE = 0.3V 


S2 Open Bn = 2V 


C, = 50 pF, Rr = 500, DE = 0.3V 
$1 Open Bn=1V 


Note 1: tp and ta skew is an absolute value, defined as differences seen in propagation delays between each of the drivers or receivers in the same package of the 
same delay, Vcc, temperature and load conditions. 


Vr 
Rr= 100 


© Voie: Yous 
VIL, VIH 


— — Note:n = 1,2,3,4 


TL/F/8698~12 TL/F/8698-2 
FIGURE 1. Equivalent Bus Output FIGURE 2. Driver Output Voitage 
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O VRn(t) 
C, = 50PF 
(INCLUDES JIG CAPACITANCE) 


AC Test Circuits 
Rp= 100 
, VDn(t) © On © Ven(t) 
VDE(t) C, = 30PF 
ne _[- cctunes JIG CAPACITANCE) 
. = TL/F/8698-3 
FIGURE 3 
' DS3893A 
VBn(t) © 


R, = 1k 


TL/F/8698-4 





_(INCLUDES JIG CAPACITANCE) =>. 


=" Note: Unless Otherwise Specified 


: : ’ The Switches are Closed .. TL/F/8698-5 
’ FIGURE 5 pa : 


‘Switching Time Waveforms 


VDn(t) 3y 
OR 
VDE(t) 3¥ 


2V 
VBn(t 
” VOL 





ta=te <4ns FROM 10% TO 90% 


: TL/F/8698-6 
FIGURE 6. Driver Propagation Delay 


2V 
vBn(t) ‘ee - 1,55V oe Bes 1.55V _ 
tPLH ‘PHL 


VOR ————_________- 
VRn(t) 1.3V 1.3V 
VOL 


ta=tp <4ns FROM 10% TO 90% 


TL/F/8698~-7 
FIGURE 7. Receiver Propagation Delay 
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Switching Time Waveforms (Continue) 


VRE(t) ” 
av 


5V 

VRn(t) 
VOL 
VOH 


VRn(t) 
: OV 
Note: ta = te < 4.ns From 10% to 90% - 


Note:n = 1, 2,3, 4 


FIGURE 8. Receiver Enable and Disable Times 


Typical Application 


2.1V 


Application Information 


Due to the high current and very high speed capability of the 


TURBOTRANSCEIVER’s driver output stage, circuit board 


layout and bus grounding are critical factors that affect the . 


system performance. 


Each of the TURBOTRANSCEIVER’s bus ground pins 
should be connected to the nearest backplane ground pin 
with the shortest possible path. The ground pins on the con- 
nector should be distributed evenly through its length. 


Although the bandgap reference receiver threshold pro- 
vides sufficient DC noise margin (Figure 9), ground noise 
and ringing on the data paths could easily exceed this mar- 
gin if the series inductance of the traces and connectors are 
not kept to a minimum. The bandgap ground pin should be 
returned to the connector through a separate trace that 
does not carry transient switching currents. The transceiv- 
ers should be mounted as close as possible to the connec- 
tor. It should be noted that even one inch of trace can add a 
significant amount of ringing to the bus signal. 


1.9V 


1.625V 
1.475V 


1.2V 
TL/F/8698-10 


FIGURE 9. Nolse Margin 
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20 OHM LOADED BACKPLANE 


DS3893A 


DS3893A 


FIGURE 10 


TL/F/8698-9 


BACKPLANE GROUND—> 


TL/F/8698-8 


STRIP=LINE BACKPLANE 


TL/F/8698-11 
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DS3896/DS3897 


ZA National 


Semiconductor 


DS3896/DS3897 BTL Trapezoidal™ Transceivers 


General Description 


These advanced transceivers are specifically designed to 
overcome problems associated with driving a densely popu- 
lated backplane, and thus provide significant improvement 
in both speed and data integrity. Their low output capaci- 
tance, low output signal swing and noise immunity features 
make them ideal for driving low impedance buses with mini- 
mum power consumption. 


The DS3896 is an octal high speed schottky bus transceiver 
with common control signals, whereas the DS3897 is a 
quad device with independent driver input and receiver out- 
put pins. The DS3897 has a separate driver disable for each 
driver and is, therefore, suitable for arbitration lines. On the 
other hand, the DS3896 provides high package density for 
data/address lines. 


The open collector drivers generate precise trapezoidal 
waveforms, which are relatively independent of capacitive 
loading conditions on the outputs. This significantly reduces 
noise coupling to adjacent lines. In addition, the receivers 
use a low pass filter in conjunction with a high speed com- 
parator, to further enhance the noise immunity and provide 
equal rejection to both negative and positive going noise 
pulses on the bus. 


To minimize bus loading, these devices also feature a 
schottky diode in series with the open collector output that 
isolates the driver output capacitance in the disabled state. 
The output low voltage is typically ““1V” and the output high 
level is intended to be 2V. This is achieved by terminating 
the bus with a pull up resistor to 2V at both ends. The device 
can drive an equivalent DC load of 18.52 (or greater) in the 
above configuration. , “Sas 


Logic Diagrams 
; DS3896N, J, M 
1 = 


if 


Aa A 


ines 
i 
linea 
ile 
A : 


i 





o . (T/R) 
| } TRANSMIT / 
RECEIVE 


TL/F/8510~1 


These signalling requirements, including a 1 volt signal 
swing, low output capacitance and precise receiver thresh- 
olds are referred to as Bus Transceiver Logic (BTLT™). 


Features 

g 8 bit DS3896 transceiver provides high package density 

a 4 bit DS3897 transceiver provides separate driver input 
and receiver output pins 

m= BTL compatible 

m Less than 5 pF output capacitance for minimal bus 
loading 

m@ 1 Volt bus signal swing reduces power consumption 
Trapezoidal driver waveforms (t,, ts = 6 ns typical) re- 
duce noise coupling to adjacent lines 
Temperature insensitive receiver thresholds track the 
-bus logic high level to maximize noise immunity in both 
high and low states 
Guaranteed A.C. specifications on noise immunity and 
propagation delay over the specified temperature and 
supply voltage range 
Open collector driver output allows wire-or connection 
Advanced low power schottky technology 
Glitch free power up/down protection on driver and re- 
ceiver outputs ti 
TTL compatible driver and control inputs and receiver 
outputs 


DS3897N, J, M 


E rift 


rah 


eh 


oh 
is 


1 
U 
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Absolute Maximum Ratings (note 1) Recommended Operating 
If Military/Aerospace specified devices are required, Conditions 
please contact the National Semiconductor Sales Min Max 
Office/Distributors for availability and specifications. Supply Voltage, Voc 4.75 5.25 
Supply Voltage 6V Bus Termination Voltage 1.90 2.10 
Control Input Voltage 5.5V Operating Free Air Temperature 0 70 
Driver Input and Receiver Output 5.5V 
Receiver Input and Driver Output 2.5V 
Power Dissipation at 70°C N Package 1480 mW 

J Package 1250 mW 
Storage Temperature Range —65°C to + 150°C 
Lead Temperature (Soldering, 4 sec.) 260°C 


L68€SQ/968ESA 


Electrical Characteristics: (Note 2and3) (0°C < Ta < 70°C, 4.75V < Vog < 5.25V unless otherwise specified) 


Symbol Conditions | Min | typ | Max_| Units 


Driver and Control Inputs: (An, Dn, En, CD, T/R, RE, TE) 


Logical “1” Input Voltage eres ee 


Logical “‘O” Input Voltage 


Logical “1” Input Current 
Logical 1” Input Current 
Logical ‘‘O” Input Current 
Logical ‘‘O0” Input Current 
Input Diode Clamp Voltage 


An = Dn = En = T/R = 2V, VL = 2V 
RL = 18.59, CD = TE = 0.8V (Figure 1) 
= Dn = En = 0.8V, Voc = 5.25V 

Bn = 2V 
An = Dn = En = 0.8V, Voc = OV 
Bn = 2v 





Bn = 1.2V, loy = —400 pA 
CD = T/R = RE = 0.8V 


Bn = 2V, Io, = 16mA 
CD = T/R = RE = 0.8V 
Bn = 1.2V 

CD = T/R = RE = 0.8V 





Note 1. “Absolute maximum ratings” are those beyond which the safety of the device cannot be guaranteed. They are not meant to imply that the device should be 
operated at these limits. The table of “Electrical Characteristic’ provide conditions for actual device operation. 

Note 2. All currents into device pins are positive; all currents out of device pins are negative. All voltages are referenced to device ground unless otherwise 
specified. 

Note 3. All typicals are given for Voc = 5V and Tg = 25°C. 
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DS3896 Switching Characteristics | 
(O°C < Ta < 70°C, 4.75V < Voc < 5.25V_uniess otherwise specified) 


Symbol Conditions , 


Driver: ae 
CD to Bn An = T/A = 2.0V, VL = 2V 
(Figure | 5 | 12 | 20 | 
T/R to Bn VC = An, VC = 5V, (Figures) | 5 | | 
CD = 0.8V, RG = 3900, CL = 30 pF 
RL1 = 180, RL2 = NG, VL = 2V 


_ Driver Output Rise Time | CD = 0.8V,T/R = 2V, VL = av 
Driver Output Fall Time , 


’ Receiver: 


~ tRLH Bn to An CD = 0.8V, T/R = 0.8V j: SOx | eee Hee | 

RHE 7 (Figure) | 5 | 10 | 18 | 
tratzo . | CDtoAn Bn = 2.0V, T/R = 0.8V, CL = 5 pF 18 

: RL1 = 3909, RL2 = NC, VL=5V_ (Figure 4) tote 
tazic Bn = 2.0V, T/R = 0.8V, CL.= 30 pF 15 

RL1 = 3900, RL2 = 1.6k, VL = 5V (Figure 4) - As 
tRHzc Bn = 0.8V, T/R = 0.8V, VL = OV, 4 
| z RL1 = 3900, RL2 = NC, CL = 5 pF (Figure 4) 
trzHo | Bn = 0.8V, T/R = 0.8V, VL-= OV, 7.- 
. RL1 = NC, RL2 = 1.6k, CL = 30 pF (Figure 4) 


taLzT T/R to An VCI = Bn, VC = 2V, RC = 180, 


CD = 0.8V, VL = 5V,RL1 = 3909, 
RL2 ='NC, CL = 5pF (Figure 5) 


taziT VCl'= Bn, VC = 2V, RC = 182, 
CD = 0.8V, VL = 5V,RL1 = 3909, 
RL2 = 1.6k,CL=30pF ‘(Figure 5) 
tayizt VCI = Bn, VC = OV, RC = 182, 
ue CD = 0.8V, VL = OV, RL1 = 3909, . 
RL2 = NC, CL = 5pF (Figure 5) 
VCl = Bn, VC = OV, RC = 189, 
CD = 0.8V, VL = OV, RL1 = NC 


RL2 = 1.6k,CL = 30pF (Figure 5) 


tnrR ’ Receiver Noise : ‘(Figure 6) 
Rejection Pulse Width ~ - 


. mote: NC means open 


DS3897 Switching Characteristics. 


(0°C < Ta < 70°C, 4.75V < Voc < 5.25V unless otherwise specified) 


symbol [Parameter [Conan 


Driver: : oe a. 
Figo) | 6 | 9 | 16 | 


An=RE=20V,VL=2v, (FiguweQ | 5 | 10 | 18 | 


12 


TE to Bn 
Driver Output Rise Time | CD = 0.8V,T/R = 2V, VL = 2V | 3 | 6 | 10 | 
Driver Output Fall Time (Figure 2) | 3 | 6 | 10 | 


1-100 








DS3897 Switching Characteristics (Continued) 
(O°C < Ta < 70°C, 4.75V < Voc < 5.25V unless otherwise specified) 


Symbol Conditions | Min | typ | Max | units 


Receiver: 


Psa o 


RE to Rn Bn = TE = 2V, VL = 5V,CL = 5pF 
RL1 = 3900, RL2 = NC 


Bn = 0.8V, TE = 2V, VL = OV, 
RL1 = 3909, RL2 = NC, CL = 5 pF(Figure 4) 


Bn = 0.8V, TE = 2V, VL = OV, 
RL1 = NC, RL2 = 1.6k, CL = 30 Ee 


Driver plus Receiver: 


Note: NC means open 


DS3896 
OR 
-DS3897 


TL/F/8510-3 


‘FIGURE 1. Driver Output Low Voltage Test 


TL/F/8510-4 


Note: t, = ty < 5 ns from 10% to 90% 
FIGURE 2. Driver Propagation Delays 
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DS3896/DS3897 


Voh 
Vo(An,Rn) 
V 


DS3896 
OR 
DS3897 


Note: ta = te < 10 ns from 10% to 90% 


FIGURE 3. Receiver Propagation Delays 


Note: t, = ts < 5 ns from 10% to 90% 


FIGURE 4. Propagation Delay from CD pin to An 
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TL/F/8510-5 


TL/F/8510-6 





_. 3V 
Vi(T/R) 
OV 
Vo (Bn) 


Vo (An) 


C (INCLUDES JIG CAPACITANCE) 


I 


, TL/F/8510~7 
Note: t, = ty < 5 ns from 10% to 90% 


FIGURE 5. Propagation Delay from T/R pin to An or Bn 


gy BUS LOGIC 
1.55V HIGH LEVEL 


-- = 2 1,25V 





BUS LOGIC 
LOW LEVEL 


TL/F/8510-8 
Note: t, = t; = 2. ns from 10% to 90% 


FIGURE 6. Receiver Noise Immunity: “No Response at Output” Input Waveforms 
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DS3896/DS3897 


30 pF 


TL/F/8510-9 
Note: t; = ts < 5 ys from 10% to 90% 


’ FIGURE 7. Driver Plus Receiver Delays 
Typical Application 


2Vv 


390, 25% 





' ps3ag6 /DS3897! ! DS3896 /DS3897; | DS3896 | /DS3897; | DS3896 /0S3897! | ps3e96 /ps3897! 
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BTL Introduction 


Chris Koehle 


Since 1985, BTL has grown from a new bus driving technol- 
ogy to the industry standard for driving high performance 
backplane buses. The evolution of BTL resulted from the 
need to replace TTL devices which are not suited to drive 
heavily loaded backplanes at very fast and reliable data 
rates. BTL transceivers are now required for the implemen- 
tation of Futurebus+ (IEEE P896) designs. In order to see 
why BTL is the technology of choice, one must first look at 
the problems BTL was designed to solve. 


The TTL Bus Driving Problem 


BTL was invented by National Semiconductor Corporation 
and first introduced in 1985 to solve the bus driving problem 
created by deficiencies in TTL drivers. TTL devices are not 
suited to drive characteristically low impedance buses which 
result from a capacitive load in each backplane card slot in 
- arunning computer system. Typical TTL bus drivers have an 
output capacitance of 12 pF-20 pF per transceiver. This, 
when coupled with the capacitive loading resulting from the 
connectors, holes, vias and printed circuit traces results ina 
lumped slot capacitance of 20 pF-25 pF. 


The high output capacitance of each board results in a low 
characteristic impedance for the backplane signal lines. In 
order to drive a signal through the threshold region, a high 
current drive is required. Most TTL devices specify a sink 
current of 64 mA-200 mA. This large current drive that is 
needed by these TTL devices results in the high transceiver 
output capacitance. In order to have incident wave switch- 
ing of a signal with these parts, (i.e., do not have to wait for 
reflections to force signal transition through threshold), even 
more current drive than that which is specified in devices 
today is required to transition a line through TTL’s 3V signal 
swing. The TTL bus driving problem arises when attempting 
incident wave switching. A TTL device must have higher 
drive current than presently available. Increasing this drive 


Increased 
Output Capacitance 


Increased 
Current Drive 


Increased 
Bus Capacitance 


Decreased 
Bus Impedance 


TL/F/11152-1 
FIGURE 1. TTL Bus Driving Problem 


current also brings about an increased output capacitance 
for the device. This scenario increases the overall bus load- 
ing and once again lowers the characteristic impedance of 
the backplane which requires even more current drive (Fig- 
ure 1). . 

The result of this cyclic problem was a compromise that had 
to be made in performance. A bus using TTL driving logic 
must rely upon reflections at the bus terminations in order to 
send the signal completely through from one logical signal 
level to another. The performance hit is evident by looking 
at the specifications for VMEbus in relation to those for Fu- 
turebus+. VMEbus requires a 35 ns settling delay for reflec- 
tions before a board can review the data or control lines that 
transitioned on the bus. The only delay incorporated in a 
Futurebus+ system is based upon the actual performance 
of the BTL drivers and receivers and time for a signal to 
propagate down a backplane. 


The BTL Solution to the Bus 


Driving Problem 


The endless cycle described above is the problem faced by 
system and transceiver designers in their quest to obtain the 
highest level of system performance that is physically possi- 
ble. 

The unique BTL solution addresses the bus driving problem 
and was originally designed by National specifically for the 
Futurebus+ IEEE specification. Since 1985, BTL has been 
adopted by many proprietary backplane bus designers and 
has become the backplane driver of choice for high per- 
formance systems, 

BTL incorporates a unique transceiver design which limits 
the amount of output capacitance for the transceiver 
(Figure 2). 


BTL Cy = 1 to 2 pF 
DRIVER veranteenns 
t 1 


BTL 
RECEIVER 


C.=1 to 2pF 


TL/F/11152-2 
FIGURE 2. The BTL Transceiver 
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BTL Introduction 


age. 


The BTL transceiver solves the output capacitance problem 
by inserting a Schottky diode in series with the driving tran- 
sistor. This isolates the driver capacitance to that of the 
reverse biased Schottky diode, and the result becomes a 
driver capacitance of 1 pF-2 pF. Another 1 pF-2 pF for a 
BTL receiver puts the total BTL device capacitance at 
<5 pF as required by the IEEE P1194 specification. The 
5 pF capacitance specification is very crucial for transceiver 
manufacturers to meet. Any excess capacitance taken up 
by a transceiver would result in system designers having to 
layout their boards with BTL transceiver to connector stub 
lengths that physically are not capable with any sized pack- 


This reduced transceiver output capacitance is only part of 


the BTL solution. BTL also specifies a 1V-signal swing with 


tightly controlled receiver thresholds. The 1V swing with the 
BTL required 80 mA drive current, enables an incident wave 
switching to occur and does not require reflections to pass a 
signal through the threshold region. The 1V signal swing 
also enables reduced power consumption. The tight receiv- 
er thresholds are required in order to guarantee accurate 
noise margin which are critical since a signal only switches 
between 1V and 2.1V. As a result, any. BTL transceiver must 
have a separate ground and Vcc pins which are only con- 
nected to separate receiver threshold control circuitry, oth- 
erwise noise margins can not.be reliably controlled. 


A BTL backplane bus is also terminated at both ends to 
2.1V, with resistors selected to match the bus impedance. A 
TTL bus with a 3V signal swing, high current drivers and 
such a large output capacitance can not be equally matched 
which also results in a less reliable signal. 


The end result of the BTL solution to the TTL bus driving 
problem can be seen in the actual backplane waveforms 
below (Figure 3). 


Slot Spacing 1.0” and Number of Slots = 18 


Fully Loaded & 
Futurebus —e i 


Fully Loaded © 
Til Bus ——»> 





20ns 
‘ oe TL/F/11152-3 
FIGURE 3. Actual BTL vs TTL Waveforms - 


The clean, reliable waveforms with incident wave switching 
has caught the eye of many proprietary system designers, 
and now with Futurebus+ about to become a standard, 
BTL is undoubtedly the bus transceiver of choice for high 
performance systems. , 











IEEE 896 Futurebus+—A 
Solution to the Bus Driving 
Problem 


The IEEE 896 Futurebus+ is a general-purpose bus stan- 
dard for high-performance microcomputer systems. With a 
strong emphasis on speed and reliability, IEEE 896 offers a 
number of innovative features that are not found in other 
backplane buses. 


A major contribution to its performance comes from its elec- 
trical specifications. Futurebus+ solves, for the first time, 
the fundamental problems associated with driving a densely 
populated backplane—as a result, it provides significant im- 
provements in both speed and data integrity. Two years of 
effort by the IEEE 896 committee have culminated in a 
deeper understanding of the physics of the backplane bus, 
leading to an ingenious solution to the bus problem. 


Speed is probably the most important feature of any bus 
standard. This is especially true for Futurebus+, since its 
‘totally asynchronous protocol permits continuous speed en- 
hancements through advances in technology. In fact, the 
maximum data transfer rate between any two plug-in cards 
is determined simply by the sum of the response times of 


the two cards and the bus delay. Ultimately, as logic devices ~ 


get faster, bus delay will be the dominating factor limiting 
bus speed. 


There are two components to the bus delay in a typical 
system, namely, the settling time and the propagation delay. 
The settling time is the time needed for reflections and 
crosstalk to subside before data are sampled; it is usually 
several times longer than the backplane propagation delay. 
As will be shown later, the settling time is the price the user 
pays for not driving the bus properly. 


By using a new technology, BTL = Backplane Transceiver 
Logic, Futurebus+ not only eliminates the settling time de- 
lay but also reduces the propagation delay of the loaded 
backplane to provide maximum possible bus throughput. 


THE PHYSICS OF THE BACKPLANE BUS 

For high-speed signals the bus acts like a transmission line 
with an associated characteristic impedance and propaga- 
tion delay whose unloaded values, Zp and tpo, are given by 


[Lo 
Z => — 
Oo Co 

too = yLoCo 
L = distributed inductance per unit length, and C = distrib- 
uted intrinsic capacitance per unit length.(t) 
These values can be calculated for a typical microstrip 
backplane (Figure 7) by means of the following equations: 

= (87/Vep + 1.41). 2 
e In [5.98h/(0.8w + t)]0 
tbo = 1.017 10.475 €, + 0.67 ns/ft 

where e, = relative dielectric constant of the board material 
(typically «, = 4.7 for fiberglass and w,h,t = the dimensions 
indicated in Figure 7. For a typical backplane, t = 1.4 mils, 
w = 25 mils, h = 4, inch, and e = 4.7. By substituting 
these values we get Zp = 1000 and tpo = 1.7 ns/ft. 


tpi, are given by 
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These values correspond to an unloaded backplane. When 
the backplane is uniformly loaded with the capacitance of 
plug-in cards and connectors at frequent intervals, the load- 
ed values of the impedance, Z,, and the propagation delay, 


ZL = Zo/V1 + (CL/Co) 
where Ci, = the distributed load capacitance per unit 
length.(1) 

The distributed capacitance, Co of the unloaded backplane 
can be measured in the lab. For our microstrip, it is 20 pF/ft. 
This does not include, however, the capacitance of the con- 
nectors mounted on the backplane and the associated plat- 
ed-through holes, which can amount to 5 pF per card slot. 


SIGNAL we. Pow | 
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. TL/E/10782- 1 
FIGURE 1. Cross Section of a Microstrip Bus Line | 


The loading capacitance of the plug-in card, however, is 
dominated by the loading capacitance of the transceiver, 
which can be 12-20 pF for TTL devices. Allowing another 
3-5 pF for printed-circuit traces and the connector, the total 
loading per-card slot can add up to 30 pF. For a system 


such as IEEE 896, which has 10 slots ES 10% Cy = 300 


pF/ft. Therefore, . 
Z = 100//1 + “{B00720) = 250 
toL = 1.7 ¥1 + (300/20) = 6.8ns/ft 


As can be seen above, the capacitive loading drastically 
alters both the impedance and the propagation delay of the 


‘bus. This reduces the bus throughput in two ways. One obvi- 


ous impact is the increased propagation delay. But the not 


’ so obvious and even more serious problem is the reduced 


bus impedance, which is much harder to drive. 

For example, to drive the loaded bus properly with a TTL 
driver which has a 3V nominal aes the required drive cur- 
rent, Ip, inust be ‘ 

Ip = BV/(Zp/2)' a 
The impedance seen by the driver is half of Z,, since froma 
given board two transmission lines ‘are being driven, one 
towards each terminator (Figure 2). Therefore, 
Ip = 3/(25/2) = 240 mA 
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This is much higher than the standard TTL’s drive capability 
of 50 to 100 mA. Figure 3 shows the effect of using a 50 mA 
driver, in this situation, on the bus waveform. The voltage 
swing on the bus has its first transition at 0.5V, the product 
of the drive current and Z,/2. This value falls well below the 
upper threshold limit of the TTL receiver. Therefore, several 
round-trip delays to the nearest termination are required for 
the waveform to cross the receiver threshold region. \n our 
example, one round-trip delay is 2tp, = 13.6 ns/ft. There- 
fore the settling times can exceed 100 ns even for relatively 
short buses. This long settling time drastically affects bus 
throughput at high speeds. Even worse, the voltage steps in 
the threshold region can’ cause multiple triggering in the 
cases of the clock and strobe signals. 


One way to solve these problems is to use 100 mA drivers 


‘with precision receivers that have a narrow threshold region 


such that the first transition crosses well over the threshold. 
This technique is widely used for clock lines to avoid multi- 


‘ple triggering. Its use on data/address lines is limited be- 


cause of the significantly higher power requirement arising 
from the large number of lines involved (32 address/data 
lines). . 

Even if power is not a limitation, switching to higher current 
drivers provides only a marginal improvement. The reason 
for this is quite simple. A higher current driver unfortunately 
has a higher output capacitance, which reduces the bus im- 
pedance further. This in turn requires an even higher current 
drive for proper operation. 


The Futurebus+ Transceiver 


A more elegant solution—one that is now a part of IEEE 
896—directly attacks the root of the problem, namely, the 
large output capacitance of the transceiver. By simply add- 
ing a Schottky diode in series with an open-collector driver 
output, the capacitance of the drive transistor is isolated by 
the small reverse-biased capacitance of the diode in the 
non-transmitting state (Figure 4). The Schottky diode capac- 


{' 


CAPACITIVE LOADING OF 
PLUG=IN CARDS 


‘ : TL/F/10782-2 
FIGURE 2. The Loaded Bus—Each Driver Sees Two Loaded Line Impedances In Parallel (2, |Z, = 21,2). . 


itance is typically less than 2 pF and is relatively indepen- 
dent of the drive current. Allowing for a receiver input ca- 
pacitance of another 2 pF, the total loading of the 
Futurebus+ transceiver can be kept under 5 pF. IEEE 896 
specifies the maximum transceiver capacitance at 5 pF. 


In addition to reducing the loading on the bus, the 
Futurebus+ transceiver features several other enhance- 
ments over a conventional TTL transceiver that drastically 
reduce power consumption and improve system reliability. 


A major portion of the power savings comes from a reduced 
voltage swing—1V—on the bus. Contrary to popular belief, 
the lower swing does not reduce crosstalk immunity (provid- 
ed the receiver threshold is tightly controlled).(2) The in- 
duced crosstalk from other lines on the bus scales down 
with the amplitude of the signal transistion causing it. Con- 
sequently, if a line receiver has a precision threshold, the 
noise margin, expressed as a percentage of signal ampli- 
tude, remains the same, as does the crosstalk immunity. 
However, the absolute noise margin, with reference to a 
noise source external to the bus, does shrink linearly with 
amplitude. Fortunately, the low impedance and the relatively 
short length of the bus make this externally generated noise 
component insignificant in high-speed backplanes. Never- 
theless, it is recommended that the backplane be shielded 
from strong noise sources external to the bus. 


Noise Immunity and EMI 


The Futurebus+ transceiver has a precision receiver 
threshold centered between the low and high bus levels of 
1V and 2.1V, respectively (Figure 5). Confined to a narrow 
region of 1.55V +75 mV (1.47V to 1.62V), the threshold 
voltage is independent of Voc and temperature. This tight 
threshold control is achieved by using an internal bandgap 
reference at the receiver input (Figure 4). And with the 
smaller 1V swing, EMI is also reduced threefold compared 
with TTL. 





DRIVE CURRENT 


The backplane impedance in IEEE 896 is specified as 52 
minimum and 622 maximum with the connectors mounted. 
In our microstrip example, due to the connector and the 
plated-through holes, a 529 minimum impedance translates 
into a maximum allowable capacitance of 5 pF per slot. This 
can be easily attained with some care in printed-circuit 
board design. A fully loaded Futurebus+ backplane there- 
fore, has an impedance whose worst-case value is given by 
100 
150 e 
1+— 
20 


Zmin = 


= 340 
The drive current required for a 1V swing is 
Ip = 1/(384/2) = 58 mA 
However, with a precision receiver threshold it is possible 
for the driver to swing past the threshold with a comfortable 
margin even if the first step climbs to only 75 percent of the 
final amplitude under worst-case loading (see again Figure 


240 mA DRIVER 


50 mA DRIVER 


THRESHOLD 
REGION 7/ 


V, = INITIAL VOLTAGE STEP 


TL/F/10782-3 
FIGURE 3. TTL Bus Waveforms— 
50 mA Driver vs 300 mA Driver 
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FIGURE 4. The Futurebus+ Transceiver 
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FIGURE 5. IEEE 896 Signaling Levels and the 
Worst-Case Bus Waveform 


5). Therefore, the drive current can be reduced by 25 per- 
cent to save power, without affecting performance: 


1 
lp = aajae? = 45mA 


BUS OUTPUT WAVEFORM 


TL/F/10782-4 
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TERMINATION 


VOLTAGE 
REGULATOR 


TL/F/10782-6 


FIGURE 6. Equivalent Futurebus+ Termination Circuit 


OTHER HIGHLIGHTS 


Bus Propagation Delay 


There is an additional benefit resulting from reducing the 
capacitive loading on the bus. This benefit arises from the 
reduced propagation delay, which further improves the bus 
speed. 


Recalculating the loaded propagation delay for the Future- 
bus+ transceiver yields 
tpL = tpo v1 + (CL/Co) 
150 


= 1.7,/1 + 30 

= 4,9 ns/ft 
This is a 30-percent improvement over the TTL example. It 
should be noted that this is the worst-case delay per foot 
and that the asynchronous nature of the Futurebus+ proto- 


col will take full advantage of lower propagation delays in a _ 


typical system, either due to lower loading levels or due to 
the closer spacing of two plug-in boards that are in commu- 
nication. 


Termination 


The drive current and the signal swing determine the termi- 
nation resistors. If the drive current is derived properly, the 
termination will match the bus impedance under the given 
loading. For IEEE 896, the value of each of the two termina- 
tion resistors, Rr, is 


1V 
Ry = (——— ] 2 = 340 = 330 
5 () 


This value is less than the loaded impedance of the 
Futurebus+, because simulations by the Futurebus+ 
Electrical Task Group show it is the best value. !n a practical 
bus, the impedance varies with the loading conditions and 
the above termination is a compromise. Simulations show 
that the best noise margins can be maintained by using the 
33N terminations. 


The P896 draft requires that the bus be terminated at both 
ends, with a single resistor of 339 connected to an active 
voltage source of 2.1V (Figure 6). This arrangement has a 
significantly lower power dissipation than a “Thévenin- 
equivalent” two-resistor termination connected to ground 


and the 5V rail. Figure 6 shows an equivalent circuit that can 
be used for terminating a few of the bus lines. Since each 
bus line has the potential of sinking 80 mA, the termination 
voltage must be able to supply adequate current for the 
worst case situation of all lines asserted simultaneously. 
The inherent inductance and decoupling capacitors of the 
termination voltage supply are crucial to the performance of 
the system. The source can be shared among bus lines as 
long as it is properly bypassed for alternating current close 
to each resistor. : 


Wire-OR Glitch 


One of the advantages of an open-collector bus is a wire- 
OR capability. This feature is fully exploited in the IEEE 896 
bus, particularly in its sophisticated arbitration protocol and 
broadcast mechanism. Unfortunately, due to the fundamen- 
tal nature of transmission lines, wire-ORing on the bus can 
cause erroneous glitches having pulse widths of up to the 
round-trip delay of the bus. The analysis of the wire-OR 
glitch is covered well by Theus and Gustavson.(5) 


To overcome the wire-OR glitch, the broadcast acknowl- 
edge lines (Al* and DI*) and the three arbitration control 
lines are required to have integrators at the output of the 
receiver capable of rejecting pulses having widths of up to 
the maximum round-trip delay of the bus. 


And More 


Geographic addressing and live insertion and withdrawal ca- 
pability are some of the other highlights of Futurebus+. 


The electrical specification of Futurebus+ is based on a 
thorough knowledge of backplane operation. A combination 
of theoretical analysis and bench measurements has been 
used to create an electrically clean bus environment. Signifi- 
cant improvements have been made in favor of higher per- 
formance—at the expense of only a slight increase in to- 
day’s cost and complexity—to assure a long design lifetime 
for the standard. The result is a proposed standard that has 


-. the performance, in terms of both speed and reliability, to 


justify the name, “Futurebus+ ”. 
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Reducing Noise on 
Microcomputer Buses 


Abstract: This paper focuses on the noise components that 
have a significant impact on the performance of a high 
speed microcomputer bus. An overview of their nature is 
followed by ways to minimize their contribution by suitable 
design of the PC board backplane, the termination network 
and the bus transceiver. The DS3662 trapezoidal bus trans- 
ceiver, which is specifically designed to minimize such noise 
on high speed buses, is presented along with its perform- 
ance data. And to conclude, some possible new transceiver 
designs for further improvement of the bus performance are 
explored. 


INTRODUCTION 


As the microcomputer bus bandwidth is extended to handle 
ever increasing clock rates, the noise susceptibility of a sin- 
gle-ended bus poses a serious threat to the overall system 
integrity. Thus, it is mandatory that the various noise contri- 
butions be taken into account in the design of the bus trans- 
ceiver, the PC board backplane and the bus terminations to 
avoid intermittent or total failure of the system. 


Although noise such as crosstalk and reflections are inevita- 
ble in any practical bus configuration, their impact on the 
system can be determined and minimized by careful design 
of all three components mentioned above. The combined 
contribution of the noise under worst-case conditions 
should be within the noise margin for reliable bus operation. 


The design of the transceiver plays a significant role in mini- 
mizing crosstalk and reflection. The bus can be optimized 
for minimum noise at a given bandwidth by using a trapezoi- 
dal driver having suitable rise and fall times along with a 
matched low pass filtered receiver which provides a sym- 
metrical noise margin. The DS3662 is one such transceiver, 
the first member in the family of trapezoidal bus transceviers 
available from National Semiconductor Corporation. This 
device represents a significant improvement in high speed 
bus circuit design and provides a solution to commonly en- 
countered bus noise problems. 


THE MICROCOMPUTER BUS 


A typical microcomputer bus usually consists of a printed 
circuit board backplane with signal and ground traces on 
one side and a ground plane on the other. The length 
ranges from a few inches to several feet with as many as 32 
closely spaced (0.6” typical) card edge connectors. Each 
signal line interacts with the ground plane to form a trans- 
mission line with characteristic impedance ‘Z’ in the range 
of 90N-1200 typical. It is desirable to have as large 
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a ‘Z’ as possible in order to reduce the drive requirement of 
the bus driver and to reduce the power dissipated at the 
terminations. But much larger values of ‘Z” translate to sig- 
nificantly larger physical dimensions and therefore are not 
very practical. 

The bus appears like a transmission line to any signal hav- . 
ing a transition time ‘t,;’ less than the round trip delay ‘2T,’ of 
the bus. The bus delay ‘T,’ is given by: 


T = LWLT CT (1) 


L = length of the bus 
L1 = distributed inductance per unit length 
C1 = distributed capacitance per unit length 
For a typical unloaded 1002 microstrip line, C1 = 20 pF/ft 
and L1 = 0.2 wH/ft. Therefore, T, = 2.0 ns/ft. This corre- 
sponds to approximately half the speed of light. However, 
the capacitive loading at each connector on the backplane 
increases the delay time significantly. The loaded delay time 
‘TL’ is given by: 


TLL = Trv1 + (CL/C}) (2) 


where C, = distributed load capacitance/unit length 


Given a 10 pF loading at each connector (connector + 
transceiver capacitance) and a 0.6” spacing between con- 
nectors, CL = 200 pF/ft and Ti, = 6.6 ns/ft. So even a 6” 
long bus has a 2T,, = 6.6 ns, which is higher than the 
transition time (t,;) of many high speed bus drivers. When in 
doubt, it is always better to use the transmission line ap- 
proach than the lumped circuit approach as the latter is an 
approximation of the former. Also, the transmission line 
analysis gives more pessimistic (worst-case) values of 
crosstalk and reflection and is, hence, safer. 


CROSSTALK REDUCTION 
The crosstalk is due to the distributed capacitive coupling 
Cc and the distributed inductive coupling Lc between two 
lines. When crosstalk is measured on an undriven sense 
line next to a driven line (both terminated at their character- 
istic impedances), the near end crosstalk and the far end 
crosstalk have quite distinct features, as shown in Figure 7. 
Their respective peak amplitudes are: 
Vue = Kne(2TL(V\/t,) fort, > 2 TL (3) 
Vue = Kne(Vi) fort; < 2TL (4) 
Vee = Kre(L)(V\/t) 
where V; = signal swing on the drive line. 


where 





2-10 


The coupling constants are given by the expressions: 
L(CcZ + Le/Z) 
4TL 
CoZ — Le /Z 


KNe = (6) 


KFE = 


The near end component reduces to zero at the far end and 
vice versa. At any point in between, the crosstalk is a frac- 
tional sum of near and far end crosstalk waveforms shown. 
It should be noted from expressions 6 and 7 that the far end 
crosstalk can have either polarity whereas the near end 
crosstalk always has the same polarity as the signal causing 
it. In microstrip backplanes the far end crosstalk pulse is 
usually the opposite polarity of the original signal. 

Although the real world bus is far from the ideal situation 
depicted in Figure 7, several useful observations that apply 
to a general case can be made: 

1. The crosstalk always scales with the signal amplitude. 


2. Absolute crosstalk amplitude is proportional to slew rate 
Vi/tp, not just 1/t,. 

3. Far end crosstalk width is always ty. 

4. For t; < 2T,, the near end crosstalk amplitude Vyye ex- 
pressed as a fraction of signal amplitude V, is a function of 
physical layout only. 


5. The higher the value. of ‘t,’ the lower the percentage of 


crosstalk (relative to signal amplitude). 
The corresponding design implications are: 


DRIVE 
INPUT 


& aie 


NEAR END CROSSTALK 


ns/ft (7) 


VNe=Kne 271 E for ty>2TL 
tr 
=KNE VI 


1. The noise margin expressed as a percentage of the sig- 
nal swing is what’s important, not the absolute noise margin. 
Therefore, to improve noise immunity, the percentage noise 
margin has to be maximized. This.is achieved by reducing 
the receiver threshold uncertainty region and by centering 
the threshold between the high and low levels., - . 


2. Smaller signal amplitude with the same transition time 
reduces bus drive regenera without penvenng noise im- 
munity. 


3. Far end crosstalk is eliminated if the receiver is decianed 
to reject pulses having pulse widths less than‘or equal to t,. 


4. When t, < 2T,, the near end crosstalk immunity for a 
given percentage noise margin has to be built into the back- 
plane PC layout. Since (Vye/V)) = Kne for this case, Kye 
should be kept lower than the available worst-case noise 
margin. Kye may be reduced by either increasing the spac- 
ing between lines or by introducing a ground line in be- 
tween. The ground line, in addition to increasing the spacing 
between the signal lines, forces the electric field lines to 


“ converge on it, significantly reducing crosstalk. 


5. For minimum crosstalk the rise and fail times of the signal 


"waveform should be as large as possible consistent with the 


minimum pulse width requirements of the bus. A driver that 
automatically limits the slew rate of the transition can go a 
long way in reducing crosstalk. 


afl 
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for tr<2Te 
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FAR END CROSSTALK 
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FIGURE 1. Crosstalk under Ideal Conditions 
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CROSSTALK MEASUREMENT 


When multiple lines on either side of the sense lines switch 
simultaneously the crosstalk is considerably larger, typically 
3.5 times the single line switching case for microstrip back- 
planes. Also, the location of the drivers on the driven lines 
and the receiver'on the sense line for worst-case crosstalk 
differs for the near end and far end cases as.shown in Fig- 
ure 2-and 3 for a uniformly loaded bus. But if the far end 
crosstalk is not of the opposite polarity, then the combined 
effect of far end and near end crosstalk could have a larger 
amplitude and pulse width at a point near the middle of the 
sense line i in Figure 2. So in a general case, or in the case of 
a non-uniformly loaded bus, it is advisable to check the 
sense line at several locations along the length of the bus to 
determine the worst-case crosstalk. The measurement 
should be made for both the positive and the negative tran- 
sition of the drive signal. 


\ 


THE TERMINATION 
A properly terminated transmission line has no reflections. 
But a practical microcomputer bus is neither a perfect trans- 
mission line nor is it properly terminated under all condi- 
tions. The capacitive loading at discrete locations, such as a 
used card slot, act as sources of reflection. However, in the 
limiting case when the bus is uniformly populated with a 
large number of modules, the bus behaves like a lower im- 
pedance transmission line. The loaded impedance ‘Z,’ of 
the bus is given by the expression: save tea an of 
eae ee a”) 
1 A+ CG; | | ae 
where Z = unloaded line impedance : 


Unfortunately, uniform loading of the bus is not gigrantags 
at all times and even if it were (by dummy loading os 


SENSE LINE 


ee ee Oe ee ee ee ee ee 


Note: All lines terminated at both ends (not shown) 


FIGURE 2. Worst-Case Far End Crosstalk Measurement. 
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Note: All lines terminated at both ends (not shown) 


FIGURE 3. Worst-Case Near End Crosstalk Measurement 








the unused slots) Z,_ is usually too low for proper termination 
of the bus. For example, a 10 pF per module loading of the 
1002 microstrip bus at 0.6" spacing results ina Z, = 309. 
One such termination at each end will require a 200 mA 
drive capacity.on the bus driver for a nominal 3V swing. 
Such large drive currents and low value terminations in- 
crease the power dissipation of the system significantly in 
addition to: causing other problems such as increased 
ground drop, inductive drops in-traces due.to large current 
being switched, etc. As a compromise the bus is usually 
terminated at an impedance higher than Z; but less than or 
equal to Z. Consequently, there is always some amount of 
reflection present. For a perfect transmission line the reflec- 
tion coefficient ‘T’ is given by the well known expression: 


Z-Rt (9) 


Posh 


where Z = impedance of the bus 
Rt = termination resistance 


The net effect, in the general case of a nonuniformly loaded 
bus, is that it may take several round trip bus delays after a 
bus driver output transition, before the quiescent voltage 
level is established. However, this delay is avoided by using 
a bus driver that has sufficient drive to generate a large 
enough voltage step during the first transition to cross well 
beyond the receiver threshold region under the worst-case 
load conditions. 

Figure 4 illustrates the driver output waveform under such a 
condition. Here the fully loaded bus (with Z_ = 309), of the 
previous example, is driven by the DS3662 bus transceiver 
at the mid point. The driver is actually driving two transmis- 
sion lines of Z_ = 302 in either direction from the middle 
and hence the initial step is given by: 


V1 = (2) als (10) 


where Ig = 
termination 


For the DS3662, the termination can be designed for 2lg = 


100 mA and therefore: . 
= (30/2)100 = 1.5V 


Fe 27 MAX 


Standing current on the bus due to each- 


This value of the initial swing is large enough to cross the 
narrow threshold region of the receiver as shown and there- 
fore no waiting period is required for the reflections to build 
up the output high level. On the negative transition the prob- 
lem is less critical due to the much higher sink capability of 
the DS3662 during pull down. 


Reflections can also be caused by resistive loading of the 
bus by the DC input current of the receiver. The resulting 
reflectoin coefficient ([) is given by the. expression: - 


Pua (2) ; ' (11) 


where Ip = receiver input current 


Having a receiver with a high input impedance not only 
makes this component of reflection insignificant but also re- 
duces the DC load on the driver, allowing the use of lower 
value termination resistors. This is particularly true when a 
large number of modules are connected to the bus. 


The design implications of the above discussion may be 
summarized as follows: 


1. If the driver has adequate drive to produce the necessary 
voltage swing under the worst-case loading (Z,/2), reflec- 
tions do not restrict the bus performance. This translates to 
a 100 mA minimum drive requirement for a typical microstrip 
bus. 

2. If the drive is insufficient, time should be allowed for the 
reflections to build up the voltage level before the data is 
sampled. 

3. For signals such as clock, strobe, etc., wherein the edge 
is used for triggering events, it is mandatory that the driver 
meet the above drive requirements if delayed or multiple 
triggering is to be avoided. 

4. An ideal TTL bus transceiver should have at least a 
100 mA drive, a high input impedance receiver with a nar- 
row threshold uncertainty region. 
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FIGURE 4. Worst-Case DS3662 Output Transition for Z, = 159 and Rr = 500 
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THE DS3662 TRANSCEIVER 


The DS3662 quad trapezoidal bus transceiver has been de- 
signed specifically to minimize the noise problems dis- 
cussed previously. The driver generates precise trapezoidal 
waveforms that reduce crosstalk and the receiver uses a 
low pass filter to reject noise pulses having pulse widths up 
to the maximum driver output transition times. Precision out- 
put circuitry optimizes noise immunity without sacrificing the 
high data rate capability of Schottky transceivers. . 


Figure 5 shows the recommended configuration for micro- 
computer buses. The use of a 3.4V source with a single 
termination resistor at each end reduces the average power 
dissipation of the bus. However, a two resistor termination 
connected between the line and the power rails, having the 
same Thevenin’s equivalent, can be substituted for lower 
cost. 


vo 
Ye DS3662 


Rr = 502 to 902 


et ‘ } ' = i . 

Using a Miller integrator circuit, the driver generates a linear- 
ly rising and falling waveform with a constant slew rate of 
0.2 V/ns (Figure 6). This corresponds to a nominal transition 
time of 15 ns. Figure 7 compares the output waveform of a 
typical high speed driver to that of DS3662 under different 
load conditions. It should be noted that even under heavy 
loading, the regular drivers have peak slew rates that are 
much higher than the average. On the other hand, the trape- 
zoidal waveform has a much lower ‘slew rate with only a 
slight increase in the transition time. Such an increase in the 
transition time has little or no effect on the data rates. In 
fact, the high fidelity of the DS3662 driver output waveform 
allows pulse widths as low as 20 ns to be transmitted on the 
bus. : 


TL/F/6281-5 


FIGURE 5. Recommended Bus Termination for Heavily Loaded Microstrip Backplanes 
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FIGURE 6. DS3662 Driver 
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Note 1: Typical high speed driver output unloaded; tr = % ~ 3ns 
Note 2: Typical high speed driver output loaded; t, = t = 10 ns 
Note 3: Typical outupt of controlled slew rate driver which is load independent; t, = t; = 15 ns 


FIGURE 7. Waveform Comparison 








The receiver consists of a low pass filter followed by a high 
speed comparator, with a typical threshold of 1.7V (Figure 
8). The noise immunity of the receiver is specified in terms 
of the width of a 2.5V pulse that is guaranteed to be rejected 
by the receiver. The receiver typically rejects a 20 ns pulse 
going positive from the ground level or going negative from 
the 3.4V logic 1 level. The receiver threshold lies within a 
specified 400 mV region over the supply and temperature 
range and is centered between the low and high levels of 
the bus for a symmetrical noise margin. 
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TL/F/5281-8 
FIGURE 8. DS3662 Receiver 


Other features of the device include a 100 »A maximum DC 
bus loading specification under power ON or OFF condition 
and a glitch-free power up/down protection on the bus out- 
put. 


ESN a 
annem 


NOISE INPUT 


RECEIVER 





—> TIME 10NS/DIV 


Waveforms in Figure 9 demonstrate the ability of the receiv- 
er to distinguish the trapezoidal signal from noise. Here the 
receiver rejects a noise pulse of 19 ns width, while accept- 
ing a narrower signal pulse (16 ns) of the same peak ampli- 
tude (the signal is triangular because of the pulse width 
which is smaller than the transition time). 


The real-world performance of the DS3662 transceiver 


shows an order of magnitude improvement in noise immuni-., 


ty over conventional transceivers under actual operating 
conditions (Reference #3). The controlled rise and fall 
times on the driver output significantly reduces both near 
end and the far end crosstalk. As expected, the pulse dis- 
crimination at the receiver input virtually eliminates the far 
end crosstalk, even on extremely long buses (over 100 
feet). The near end crosstalk, which is particularly severe on 
the state of the art backplanes due to the tight spacing be- 
tween the signal lines, is easily accommodated by the large 
percentage noise margin (>75%) provided by the receiver. 
Field reports indicate that the DS3662 not only solves those 
mysterious intermittent failure problems in mini and micro- 
computer systems, but also helps them meet the new FCC 
emission requirements due to the reduced AF radiation from 
the bus. . 
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FIGURE 9. DS3662 Receiver Response 
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FIGURE 10. High Speed Bus Transceiver with Low Output Loading for MicroComputer Backplanes 
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WHAT NEXT? 


Since crosstalk scales with the signa! amplitude, reducing 
the signal swing has not effect on the noise immunity as 
long as the percentage noise margin remains the same. On 
the other hand, there are several advantages in having low- 
er signal swing. It reduces the drive current requirement of 
the driver thus reducing its output capacitance. Lower ca- 


. pacitive loading on the bus decreases its impedance reduc- 


ing the drvie requirement even further. Having a lower.cur- 
rent drive not only reduces the power dissipated at the ter- 
minations but also allows better matching of the termination 
due to the increased line impedance. In the ideal limiting 
case the driver has negligible loading effect on the bus and 
thus allows perfect termination under all load conditions. 


In practice however, there are some obvious limitations. The 
receiver thresholds have to be maintained within tighter lim- 
its at lower signal swings to maintain the same percentage 
noise margin. Also, the capacitive loading is difficult to re- 
duce beyond a certain point, due to the diminishing return in 
the way of lower current-rating, as the loaded bus imped- 
ance approaches the unloaded impedance. However, the 
capacitance of an-open collector driver output can be re- 
duced significantly by using a Schottky diode as shown in 
Figure 10. The diode isolates the driver capacitance when 
the output is disabled. Using reduced signal swings and pre- 
cise receiver thresholds, such a transceiver can provide sig- 


nificant improvements in microcomputer bus performance. 
The transceiver design presented in Figure 70 is being con- 
sidered for incorporation into the Futurebus standard by the 
IEEE. SAAT TE EM 
CONCLUSION os . 


A well designed bus transceiver goes a long way in improv- 
ing the noise immunity of a single-ended TTL bus. Further 
improvements in bus performance may come from the use 
of reduced voltage swings and better transceiver designs 
for lower bus loading and tighter receiver threshold limits. 
Although such approaches may not be TTL compatible, the 
improvement in performance gained may indeed justify a 
new standard for bus transceivers. 
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Timing Analysis of 
Synchronous and 
Asynchronous Buses 


ABSTRACT 


This paper presents detailed examples of bus timing calcu- 
lations for both synchronous and asynchronous busses, 
showing that bus throughput can be maximized by taking 
into account the characteristics and limitations of the trans- 
ceiver technology being used. Based on these examples, a 
performance analysis of the currently available high speed 
bus interface technologies is made in terms of their maxi- 
mum attainable transfer rate on both types of backplane 
busses. The results show that the use of a faster transceiv- 
er, as judged by its data sheet, doesn't necessarily result in 
a faster bus. 


INTRODUCTION 


In order to derive the highest possible throughput from a 
backplane bus, a careful analysis and optimization of timing 
parameters is essential. The maximum speed attainable at 
the physical level of the bus is a function of the transceiver 
technology, the electrical length of the bus, and the type of 
protocol, synchronous or asynchronous, being used. A clear 
understanding of the bus timing constraints lets the design- 
er take best advantage of a given technology, such as TTL, 
ECL, or BTL (Backplane Transceiver Logic). Contrary to in- 
‘tuitive thinking, a faster transceiver will not always result in a 
faster bus. It can be shown through examples that greater 
bus transfer rates can be obtained by using specially de- 
signed bus transceivers, such as the BTL Trapezoidal, that 
at first glance may appear to be slower than the equivalent 
AS or FAST devices. These devices, in addition to improv- 
ing bus bandwidth, also reduce crosstalk, ground noise, and 
‘system power requirements. 


BUS PROPAGATION DELAY AND SETTLING TIME 


Traditionally, system designers have used standard TTL de- 
vices to drive the backplane bus. Unfortunately, although 
‘TTL appears to provide fast rise and fall times, it cannot 
cleanly drive the capacitance of a loaded backplane or the 
resistance required for proper termination. BTL technology 
is a result of work that was done within the IEEE 896.1 
Futurebus committee specifically to solve the problems of 
driving a backplane with transmission-line characteristics. 
By using a smaller voltage swing, lower capacitance drivers, 
and receivers with precision thresholds, BTL transceivers 
overcome the ‘‘bus driving problem.” 


Simply. stated, the problem is one of driving a ae imped- 
‘ance transmission line (Figures 7 and 2). The capacitive 
loading of a bus due to TTL transceivers reduces its imped- 
ance from an unloaded value of 60-1000 to a fully loaded 
impedance of less than 200. A properly matched termina- 
tion resistance would therefore require a current of over 
300 mA in order to cleanly drive a 3V nominal TTL swing! 
Since most TTL drivers cannot supply this current, they 
must depend on reflections to build up the bus voltage to a 
DC level. This results in a settling-time penalty of one or 
more bus round-trip propagation delays on every signal 
transition, or 35 ns on a typical 20” TTL bus. 
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The low output capacitance of BTL transceivers allows the 
total capacitive loading of a card in a backplane to be kept 
under 10 pF. This doubles the impedance of a loaded bus to 
almost 30. BTL also specifies a reduced signal swing of 
1V, which allows a properly terminated bus to be driven 
cleanly at under 75 mA. Consequently, there are no reflec- 
tions, and the settling time is zero. A BTL driver can be 
guaranteed to cross the threshold of every receiver on the 
backplane with the incident edge of a signal wavefront. 


The propagation delay of a bus is also a strong function of 
the capacitive loading. In the TTL case, the capacitive load- 
ing increases the signal propagation delay by a factor of 3 to 
5 over an unloaded bus. In a 20” bus, BTL can reduce this 
delay from a value of 13 ns in the TTL case to less than 
9 ns, increasing the potential bus bandwidth significantly. 


SYNCHRONOUS BUS TIMING 


For our first example, let’s consider burst data transfers on 
a synchronous bus. In many backplane systems, . burst 
transfers provide the highest performance, because the 
overhead associated with the address cycle can be spread 
out over a number of data cycles. Although other types of 
transactions may be more complex and require more time 
(clock cycles), it is likely that many systems will be opti- 
mized for burst transfers. 


In this example, we are making some simplifying assump- 


“tions which ignore some of the penalties associated with a 


general-purpose synchronous bus. One of these is that the 
entire interface is synchronized to the bus clock. In general, 
each card in a backplane will be running off of its own inter- 
nal high-speed clock. This results in resynchronization me- 
tastability problems at both the master and slave interfaces, 
as well as a clock latency penalty of typically 50% of the 
clock period. We are also ignoring the return of status from 
the slave on each data transfer, by assuming all status can 
be generated before the data is clocked. This would not be 
true, for example, if parity had to be verified peters me next 
data transfer could take place. 


Clock Skew 


In this example, the ee clock is being distributed to 
each board through a clock line on the backplane. Since the 
clock line is being driven from a single point, the loaded 
capacitance on it is considerably less than on most other 
lines, and the settling time is typically zero, even in a TTL- 
based backplane. Due to the finite propagation delay across 
the bus, however, the clock edge still arrives at each board 
at different times, creating a relative edge inaccuracy com- 
monly referred to as clock skew. 


The worst-case skew can be cut in half by locating the clock 
source centrally on the backplane, rather than at one end. 
Additional clock skew will be introduced by the propagation 
delay differences in the receiver and logic gates that pro- 
cess the clock signal between boards. For a typical 20” 
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data sheet 


TL/F/9633-1 


BTL (Trapezoidal) 


TL/F/9633-2 


FIGURE 1. Settling Times 


bus, with the clock driver located at the midpoint, total skew 
can easily exceed 10 ns; in our case, 5 ns for the bus, plus 
7 ns for the receiver and a transparent latch used to imple- 
ment bus wait states. 


Synchronous Data Transfer Timing 


In this example (Figure 3), the worst case data propagation 
delay from the master to the slave is simply the sum of the 
delays of the individual components of the data path. This 
path travels through the master’s edge-triggered flip-flop 
and bus driver, across the length of the bus, and then 
through the slave's bus receiver and flip-flop, where the in- 
coming data is latched. However, because this is a synchro- 
nous system, the data can be “pipelined” to some extent 
within the intervening logic. This means that the minimum 
clock cycle possible under this configuration is the sum of 
the logic skews, plus the maximum bus propagation delay, 
the set-up and hold times of the receiver, and the clock 
skew (Figure 4). 

The advantage of a synchronous system is that the abso- 
lute timing requirements are set by the clock; the entire sys- 
tem can be optimized with this constraint in mind. This can 
become a disadvantage as technology advances beyond 
the point at which the synchronous bus was designed. A 
synchronous system must be continually redesigned for 
higher clock rates in order to take advantage of improve- 
ments in technology. Synchronous busses are therefore 
more suited to specific applications than to general-pur- 
pose, extended lifespan products. 
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Synchronous Timing Calculations 

The first set of calculations assumes a TTL bus with AS 
transceivers and logic. As can be seen, the bus settling time 
overwhelms all the other skews and delays in the system. 


_ The upper limit of a discrete TTL synchronous bus imple- 


mentation is roughly 15 MT (megatransfers/second). No 
particular advantage is gained by using FAST devices be- - 
cause, while the maximum propagation delays specified for 
that family are shorter than for AS, the maximum skews are 


generally greater. The effect of skew specifications is anoth- 


er subtlety of system performance analysis. 


Two types of BTL transceivers are currently available, the 
BTL Trapezoidal and the BTL Turbo. The Trapezoidal trans- 
ceivers have controlled rise and fall times on their drivers of 
6 ns (nominal) to reduce crosstalk interference and switch- 


-ing noise within the backplane. In addition, the receivers 


incorporate crosstalk filters that practically eliminate far-end 
crosstalk problems on the bus. The Turbo transceivers elim- 
inate these Trapezoidal features, but are much faster as a 
result. Switching noise problems are overcome by the use 
of individual ground return lines for each driver. Stripline 
backplane construction and careful layout techniques are 
required to minimize crosstalk. . 


Although the BTL Trapezoidal transceiver delays are much 
greater than those of the TTL devices, the absence of set- 
tling time results in a smaller overall clock cycle time. A 
maximum transfer rate of 18 MT becomes possible. When 
the Turbo devices are used, system throughput increases to 
24 MT in this discrete implementation. 








7 rr L; 
dig Wet Cap 


Cy (TTL) = 25 pF/0.8" = 375 pF/tt. 


re TL/F/9633-3 
Cy (BTL) = 10 pF/0.8” = 150 pF/ft. 


Zo = 762 Unloaded Bus Impedance 

Co ~ 20pF/ft. . Distributed Capacitance of Unloaded Bus 
To ~ 1.8 ns/ft. Unloaded Bus Propagation Delay 

ZL = Zo/V1 + (CL/Co) Loaded Bus !mpedance 
TL. =L X To xX ¥1 + (CL/Co) Loaded Propagation Delay 


Ty (TTL) = 13.3ns TL (BTL) = 8.75ns 


FIGURE 2. Effects of Capacitive Loading 


CLK '374 


HOLD 


NEW DATA IN DATA OUT 
FIGURE 3. Synchronous Bus Logic for Burst Data Transfers 


TL/F/9633-4 


BTL 
. Trap Turbo 
1) Max ’374 Skew A 5.0 5.0 
2) Max Bus Driver Skew 4.5 10.0 5.0 
3) Max Bus Delay 35.0 9.0 9.0 
4) Max Bus Receiver Skew 4.5 13.0 6.0 
5) Max '374 Setup and Hold 5.0 5.0 5.0 
6) Max Clock Skew 12.0 12.0 12.0 


TOTAL (ns) 66.0 54.0 42.0 
MTransfers/second 18.5 18.5 23.8 


FIGURE 4. Synchronous Burst Data Transfer Timing 
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DELAY 1 


1) Max XOR Delay 

2) Max ’374 Delay 

3) Max Data Driver Delay 

4) <Min’533 Delay> 

5) <Min Sync Driver Delay> 


TOTAL (ns) 


DELAY 2 


1) Max XOR Delay 

2) Max ’374 Hold Time 

3) Delay 3 

4) <Min’373 Delay> 

5) <Min Ack Driver Delay> . 
5) <Min Dale Receiver Delay> 


TOTAL (ns) 


DELAY 3 


1) Max Data Receiver Delay 

2) Max '374 Setup Time 

4) <Min Sync Receiver Delay> 
5) <Min XOR Delay> 


TOTAL (ns) 


FIGURE 6. Asynchronous Bus Logic Delay Calculations 
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CLK '374 


TL/F/9633-5 


TL/F/9633-6 


TL/F/9633-7 


TL/F/9633~8 





1) Max Ack Receiver Delay 
2) Max ’533 Delay 

3) Delay 1 

4) Max Sync Driver Delay 

5) Max Bus Delay + Skew 
6) Max Sync Receiver Delay 
7) Max '373 Delay 

8) Delay 2 

9) Max Ack Driver Delay 

10) Max Bus Delay 


TOTAL (ns) 
MTransfers/second 


6.0 
7.5 
6.5 
35.0 


133.0 
7.5 


10. 0 
8.0 
6.0 
9.0 
‘7.0 
.9.0 


88.0 
11.4 


FIGURE 7. Asynchronous Burst Data Transfer Timing 
(Worst Case) 


The largest cycle time delay in the final BTL Turbo example 
is clock skew. Bus skews can be reduced by distributing the 
clock to each board independently, using a dedicated trace 
on the backplane such that all lines are of equal length. This 
makes the clock propagation delay from the driver to each 
board the same, and thus practically eliminates the bus 


skew. In addition, better tolerances on driver, receiver; and 
logic propagation delays (smaller skews) will improve both 
the clock skew and the effect of transceiver delays on the 
cycle time. 


ASYNCHRONOUS BUS TIMING 


Our second example is also of a burst transfer, but this time 
using asynchronous bus timing. In this system, the master 
issues a strobe along with the data, and waits for an ac- 
knowledgement from the slave before removing the current 
data from the bus lines. All timing is controlled by the two 
participants in the data transfer. (Once again, we are as- 
suming that new status does not have to be generated on 
each data transfer.) 


The greatest advantage of an asynchronous bus protocol is 
its ability to adapt the speed of the bus to the speed of any 
two communicating boards. The most flexibility is achieved 
when no technology dependencies are introduced into the 
protocol..Unlike a synchronous system, where every board 
is designed with the same timing constraints in mind, a tech- 
nology-independent module is designed with no assump- 
tions about the timing.of the rest of the system. Instead, 
each transmitting board simply guarantees that its data is 
valid on the bus at least zero nanoseconds before it issues 
its synchronization signal, and each receiving board is re- 
sponsible for ensuring that its data has been successfully 
latched before issuing an acknowledge. The protocol itself 
imposes no artificial set-up or hold time limitations. 
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The result of this lack of timing constraints is that a board 
built today, using today’s technology, is guaranteed to work 
in a system designed perhaps twenty years from now. That 
system will be forced to slow down whenever necessary to 
accommodate the greater internal delays and skews of the 
older module: However, if two future modules are communi- 
cating, they will transfer data at the maximum rate allowed 
by the future technology. The new IEEE Futurebus standard 
implements this type of protocol. 


ASYNCHRONOUS DATA TRANSFER TIMING 


The requirement that boards generate their own data syn- 
chronization and acknowledge signals, and the likelihood of 
zero set-up and hold times on the bus, make the timing of 
the asynchronous system more complicated than the previ- 
ous example (Figure 5). Also, we are maximizing the per- 
formance of the sync/ack handshake by transferring data 
on each signal transition. This is known as a two-edge hand- 
shake. 


On the master side, the board must guarantee that its data 
is valid on the bus before issuing the synchronization signal. 
This means that a delay must be inserted in the sync signal 
path (Delay 1) which includes the maximum propagation de- 
lays through the XOR clock generation circuit, edge-trig- 
gered flip-flop, and data bus driver. This is excessive, how- 
ever, because the minimum delays through the sync latch 
and bus driver can be subtracted (Figure 6). 


On the slave side, delays are required to guarantee that 
both the set-up and hold time specifications of the data 
latch are met. The set-up time delay (Delay 3) ensures that 
the sync signal, which may have minimum propagation de- 
lays through the sync bus receiver and XOR clock genera- 
tor, arrives at the edge-triggered data flip-flop a set-up time 
after the data, which may have a maximum delay through 
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1) Min Ack Receiver Delay 
2) Min ’533 Delay 

3) Delay 1 

4) Min Sync Driver Delay 

5) Min Bus Delay + Skew 
6) Min Sync Receiver Delay 
7) Min ’373 Delay 

8) Delay 2 

9) Min Ack Driver Delay © - 
10) Min Bus Delay 


TOTAL (ns) 
MTransfers/second 


109.0 


BTL 
Trap Turbo 
5.0. - 2.0 
4.0 4.0 
16.0 21.5 16.5 
2.0 5.0 2.0 .. 
35.0 1.0 1.0 
2.0 5.0- 2.0 
3.5 3.5 3.5 - 
7.5 10.0 9.0 
2.0 5.0 2.0 
35.0 0.0 0.0 


60.0 42.0 


9.2 16.7 23.8 


FIGURE 8. Asynchronous Burst Data Transfer Timing 
(Best Case) 


the data bus receiver. The hold time delay (Delay 2) ensures 
that the data remains at the data flip-flop a hold time after 
the sync signal, which this time may have a maximum prop- 
agation delay through the XOR and the set-up time delay 
element just introduced. Since the removal of data is con- 
trolled by the ack signal, the hold time delay can be reduced 
by the minimum delays through the ack latch and bus driver, 
and the minimum propagation delay of the data bus receiv- 
er. 


This is all very confusing at first, but these delay elements 
now in place in our circuit guarantee the receiver set-up and 
hold time requirements while maintaining the technology in- 
dependence of the bus protocol. Now we can calculate the 
burst data transfer rate on this asynchronous bus. 


The critical path is now the sync/ack handshake. The circuit 
delays are in place to make sure that data is transferred 
successfully. To calculate the transfer rate, simply add up all 
the propagation delays through the sync/ack loop (Figures 
7 and 8): on the master, the ack receiver, the sync latch, 


‘Delay 1, and the sync driver;'a bus propagation delay; on 


the slave, the sync receiver, the ack latch, Delay 2, and the 
ack driver; and another bus propagation delay. 

Should you use worst-case values throughout your evalua- 
tion? The beauty of a technology-independent asynchro- 
nous protocol is that is will adapt to the speed of the individ- 


‘ual logic elements in the sync/ack handshake path. If all the 


devices happen to have worst-case characteristics, then 
yes. If they are all fast parts, however, then data transfer will 
take place under best-case conditions. Both calculations 
are included, route the periee operating anges of the 
clreult. 
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ASYNCHRONOUS TIMING CALCULATIONS 


Once again, the TTL design is overwhelmed by the settling 
time of the bus. Since the sync/ack signal pair are acting as 
clocks in this system, glitches that may occur during: the 
signal settling time are intolerable. This means that the 
35 ns bus settling time must be hard-wired into the receiver 
logic, and cannot be reduced under best-case conditions. 
The performance of an asynchronous TTL backplane, from 
7.5 to 9.2 MT, cannot approach that of a similar SynciNe: 
nous backplane. 


The BTL Trapezoidal system has very similar performance 
to a TTL backplane under worst-case conditions. However, 
because there is no settling time penalty associated with 
BTL signals, the effect of improvements in device operation 
have a far more pronounced effect. In the best case, the 
performance is close to that of the equivalent synchronous 
system. Also, since the bus signal propagation delay is a 
function only of the distance between the two boards, mod- 
ules placed in adjacent slots will experience aincst no 
backplane delays. 


A BTL Turbo board benefits from the same clean electrical 
environment that a Trapezoidal one does, except with a 40- 
50% overall improvement in performance. In the best case, 
the performance is the same as that of the equivalent syn- 
chronous system. Of course, as device parameters i improve, 
with lower propagation delays and skews, the performance 
of the asynchronous system will continue to improve. The 
largest reductions in the transfer cycle time will come as 
interfaces for asynchronous busses such as Futurebus are 
integrated onto a single piece of silicon, where skews and 
delays can be more tightly controlled. — 





CONCLUSION 


The use of transceivers designed specifically for the trans- 
mission-line environment typical in today’s high-speed back- 
planes provides advantages in both the performance and 
electrical integrity of a system. The advantages of BTL only 
become obvious after a careful analysis of data transfer tim- 
ing considerations. The Trapezoida! and Turbo options pro- 
vide a designer with the opportunity to make the appropriate 
application-dependent cost/performance tradeoffs. A 
sometimes controversial issue is the appropriateness of a 
synchronous versus an asynchronous design. The former 
will usually provide an immediate performance advantage in 
a fully synchronized environment, but a carefully-designed 
general-purpose asynchronous BIpIerr will often have a 
longer useful product life. 
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TABLE |. Device Parameters 


Parameter 


Device — 


DM74AS374 
Edge-Triggered Flip-Flop 
DM74AS373 
Transparent Latch 


DM74AS533 
Inverting Transparent Latch 


DM74AS86 
2-Input XOR 


DM74AS240 
Bus Driver/Receiver 


DM74AS242 
Bus Transceiver 


DS3896 
BTL Trapezoidal Transceiver 


DS3893 
BTL Turbo Transceiver 


Note: Values in boldface are those used in the preceding calculations. 


Minimum 
Prop. Delay 
6.0 
4.0 7.5 
ee ay a cieaird 
Other Input L 
Other Input H 
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Maximum 
rreP. ney 


6.5 4.5 
6.0 5.0 


LH 6.5 4.5 
HL 5.7 3.7 


LH! 6.5 4.5 
HL 5.7 3.7 
es 18.0 

15.0 
8.0 6.0 
7.0 5.0 
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Signals in the eae 
es le 


The Futurebus + backplane is a complex electrical environ- 
ment that consists of many circuit elements. The modeling 
of such an environment can become time consuming and 
expensive. The Futurebus+ Electrical Task Group Expert 


Team has detailed the ‘circuit elements in their SPICE simu- 


lation. An average Futurebus+ simulation contains over 


10,880 individual elements.and gobbles 8 CPU hours ona | 


single user VAX 8650. This note is an attempt to simplify the 


circuit model and gain an intuitive understanding of interac- _ 


tive signal path elements. The elements are investigated by 
probing at individual impedance breaks that are considered 
significant. Waveforms of the signal will be correlated with 


the TDR signals from the same signal paths. An investiga- - 


tion of ground signal variations and crosstalk measurements 
is included because of relevance to signal measuring in this 
environment. The relation between the crosstalk, ground 
bounce and the signal path impedance will be pursued to 
see their combined effect on the noise margin. . 

The interconnect effects on the electrical signal become 
critical in high speed multilayer board design such as Futu- 
rebus+. PCB traces must be treated as transmission lines 
due to the rapid transition times of the signal. Analyzing 


RTI = 390 
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Application Note 738 - 
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PCB traces uncovers the impedance mismatches caused by 
seemingly harmless corner geometries, parasitic and cross- 
over effects, and inter-layer vias. The impedance mismatch- 
es also affect crosstalk coupling and signal reflections | 
which are a major concern due to the large chunk of noise | 
margin they may.consume. To demonstrate how these cir- 
cuit elements affect the signal, this article will follow a signal 
from the transceiver as it propagates into the backplane. 


FUTUREBUS+ BACKPLANE AND BOARD MODEL 


Figure 1 models the signal path from a transceiver in one 
board, through the backplane, to a transceiver in another 


_ board. Both of the boards are mounted in a ten slot back- 
- plane. The dashed line to one module indicates it can be 
_femoved or moved around to different locations for this 


analysis. It is the receiver and it is seen as a load by the 
driver module. To first: emphasize the driver module stub 
effects alone, the receiver is not inserted into the back- 
plane. This focuses the driver response to only the trans- 
mission line elements. This model can be generalized to any 
backplane. However, it is derived from specific equipment 
used to obtain these waveforms. The backplane is provided 
by Bicc-Vero Electronics, No. 819-304105E. It uses 390, 


BACKPLANE TO CONNECTOR 
SOLDER POINT 


RT2 = 390 
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CONNECTOR VIA” 
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CONNECTOR 
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Model of the Futurebus+ backplane with two daughter boards; one in slot 1, and one in slot 5 with an input signal at pin 10. 


FIGURE 1 
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FIGURE 2. Eight Layer Daughter Board, Side View 
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FIGURE 2a. PCB Track Cross Section 


surface mount, termination resistors and has a 1 inch spac- 
ing between the slots (soft metric). The board is provided by 
Hybricon. It is a Futurebus+ Wire-Wrappable Board 6U x 
280mm. The part number is 031-126-10. The board is laid 
out (eight layers) for the: National Semiconductor Future- 
bus+ Chip Set transceivers and can accommodate 64 data 
bits. 

Figure 2 is a cross section of the Hybricon board showing 
the signal path of the DS3886 Latched Data Transceiver, 
pin-36. The illustration emphasizes the physical impedance 
differences of the transmission path elements. Examination 
of the Time Domain Reflection response of the signal path 
is a. good way to “electrically see” these differences. 


TIME DOMAIN REFLECTION 


TDR uses a step generator to apply a positive going impulse 


to the signal path being investigated. The step has a very 
fast rise time of 35 ps and a 200 mV amplitude. The step 
travels down the path at the propagation velocity of the line. 
If there are impedance mismatches in the signal path, part 
of the incident wave will be reflected. The reflected wave is 
then algebraically added to the incident wave at the point 
where the mismatch occurs. The total voltage wave appears 
on the oscilloscope as a road map to the impedance breaks 
encountered by the propagating step. 


A quick review of reflection coefficient (p) fundamentals will 
be helpful to intuitively understand the effects of signal path 
impedance breaks. Then, investigating three load imped- 
ance conditions will suffice. For all cases, the TDR gener- 
ates the step from a 502 source and it is carried by a cable 
with characteristic impedance, Zq = 50, to the de- 


TL/F/11107-3 


vice under test, DUT. First case is if the DUT were a 509 
load, then p would be 0 and the wave on the scope would 
appear as a straight line after the step, no reflected wave 
added to the incident. 


p = (2, — Zo)/(Z_ + Zo) = OforZ_ = Zo 
Zo = cable characteristic impedance 
ZL = load impedance 


The equation for adding the reflected wave, Er, to the inci- 
dent wave, Ei, is as follows. 

E = Ei + Er, where Er = Ei(p) 
The second case is infinite load impedance as in Figure 3a. 
p is equal to +1 in this case and the reflected wave equals 
the incident wave. The total wave is then double the inci- 
dent, Figure 3b. Now consider when the incident wave hits 
an inductive impedance. The current can’t change instanta- 
neously so the load momentarily appears as an open due to 
the increased impedance. The p = +1 att = 0 in Figure 
3c. Reflected voltage is ideally the same as the incident 
voltage for that moment. As the inductor current builds ex- 
ponentially, the impedance drops toward zero, Figure 3c. 
The voltage a long time after t = 0 is determined by resist- 
ance in series with the inductor. As t goes to infinity, the 
reflection coefficient is p = (R — Zo)/(R + Zo), where 
R = series resistance of the inductive load. 


Z =. 
TL/F/11107-4 
FIGURE 3a 
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FIGURE 3b 
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FIGURE 3c 
The third case is zero load impedance as in Figure 4a. p= 
—1 and the reflected wave is subtracted from the incident 
wave leaving no voltage. Expanding on this idea, when the 


incident wave hits a capacitive impedance, the capacitor 


won't accept a sudden voltage change. No change in volt- 
age appears as a short circuit instantaneously and p = —1 
att = 0. The capacitor voltage builds exponentially and the 
impedance rises to a level determined by the shunt resistive 
component of the load, Figure 4c. The final value of p is 
again (R — Zo)/(R + Zo), only R = shunt resistance of the 
capacitive load. 


ZL ——e. 
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FIGURE 4a 
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FIGURE 4b 
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TDR AND IMPULSE ENERGY 


Another way to look at TDR results is by considering the 
energy contained in the step impulse. This energy is trans- 
mitted over a non ideal medium so there are losses, but for 
short distances it is not unrealistic to consider the energy of 
the pulse to be constant. Now consider the capacitive im- 
pedance break; increasing capacitance reduces the charac- 
teristic impedance. 


V/I = Zo = v(Lo/Co) where: 
Lo = inductance per unitlength 
Co = capacitance per unit length 
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Since the energy of the pulse remains constant and the 
voltage and the impedance drop, the current must increase 
proportionally to the lowered voltage. This increased current 
charges the capacitor at a time constant that is determined 
by Zo in parallel with the shunt R to the capacitor..As the 
capacitor stores the energy, the current drops off and the 
capacitor appears as an open circuit after a long steady 
state condition. 


TDR SYSTEM ERRORS 


The extremely fast rise time of the step impulse is important 
to TDR analysis. Since the leading edge of the incident step 
is made up almost entirely of high frequency components, it 
accentuates the small reactive impedance mismatches of a 
signal path. As the step travels down a non-ideal transmis- 
sion line, the higher frequencies are attenuated by skin ef- 
fect losses and dielectric losses. This distorts the step, and 
is called cable loss. The degraded rise time limits the accu- 
racy of reflection measurements through a multiple disconti- 
nuity signal path. TDR measures each succeeding disconti- 
nuity with less accuracy, because the transmitted step de- 
grades and multiple reflections occur. The stub of a daugh- 
ter board qualifies as a multiple discontinuity path, so the 
resulting waveforms must be analyzed as such. 


TDR AND FUTUREBUS+ SIGNAL STUBS 


With this in mind, an analysis of the TDR waveforms of the 
signal path can be performed. Figures 5a and 56 show the 
artwork for two signal path traces. The actual path length is 
64mm. Figure 5a is the path used for all the waveforms 
gathered in this analysis and Figure 5b is a path for compari- 
son of the TDR responses. The apparent similarity of the 
artwork does not show the electrical differences of the 
paths while the TDR waveforms do. Figures 6 and 7 include 
the waveforms from these two signal paths that are similar 
but different enough to demonstrate some characteristics. 
The signal path from pin 36 of the DS3886 goes through 
connector B-b-16 as designated by the Futurebus+ stan- 
dard, Figure 5c. This path is included in both figures. Also in 
both figures is the reflection from just the SMA connector 
that is used to launch the step impulse into the signal path. 
It is terminated with a 502 load. The inductance of the SMA 
leads can be seen by the sharp increase in impedance. The 
return to the 500 level is then illustrating the first case in the 
TDR review for the p = 0 situation. 


MICROSTRIP 
STRIPLINE | 


INTER-LAYER VIA 


_.TL/F/11107-10 


FIGURE 5a. Signal Path B-b-16 
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FIGURE 5b. Signal Path B-c-16 
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FIGURE 5c. Signal Connector Block B, Rows 13 to 18 








Figure 6 shows the effect of launching the TDR step into the 
solder pad. The first inductive bump is the error introduced 
by ‘the SMA launching mechanism. The inductance of the 
microstrip follows the dip in impedance (capacitive solder 
pad). The path impedance is raised to 752 by both signal 
paths, Figure 7. Notice how the longer microstrip in Figure 
$a adds distance to the inductive bump compared to the 
waveform from the shorter microstrip in Figure 5b. Then no- 
tice that the inter-layer via causes a capacitive drop in im- 
pedance. The stripline impedance settles in at about 602 
for both of the paths. The next dip is the capacitance of the 
connector -via solder point followed by the inductive in- 
crease of the connector wires. Notice that the longer “c” 
wire increases the impedance more than the “‘b” wire. Final- 
ly, the step hits the open end of the connector and the 
signal voltage doubles which indicates the p = 1 situation. 


200 ps/div . 


Figure 6a is included to show how the degradation of the 
incident wave through the multiple impedance mismatches 
of the signal path affects impedance level measurement. 
The TDR impulse is launched into the connector end of the 
path rather than the solder pad end. The difference is best 
seen in how the impedance of the connector is much great- 
er when the high frequency components of the incident 
wave have not been attenuated by the previous impedance 
mismatches. The connector launch displays an impedance 
of 902 rather than the small increase that is shown in the 
end of the launch from the solder pad. Figure 6a also shows 
the capacitance of the transceiver mounted on the solder 
pad that is charging to the open state at the time constant 
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_ FIGURE 6. Two TDR Waveforms, 502 Termination and Path B-b-16 
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FIGURE 6a. TDR Launch into Connector B-b-16 with DS3886 Mounted On Board 
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FIGURE 7. Three TDR Waveforms 
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THE TRANSCEIVER IN THE UNLOADED BACKPLANE 


The transmitting transceiver is mounted in slot 5, Figure 7. 
Pin 36 is named B3 in both the DS3883, 9 Bit Data Trans- 


ceiver, and the DS3886, the Latched Data Transceiver 


which is used in this application. Pin 37 is the B3 GND pin, 
the BTL ground for B3 (see section on BTL, QGND, and 


logic GND). The signal waveform in:Figure 8 is.obtained by ... 


probing the circuit with a low inductance ground tip at these 
two pins. The signal displays a rapid fall time, large over- 
shoot and minimal 'undershoot. This signal is different than 
that obtained from bench testing with minimal jig inductance 
and capacitance, Figure 8a. That waveform shows slower 
fall time and no overshoot. There are a couple of reasons 
for these backplane circuit responses. The ‘first being the 
microstrip circuit. element, T(55,365). Physically, this ele- 
ment'is a very narrow microstrip between the solder pad 
and the inter-layer via. The relatively high inductance of this 
microstrip; shown in Figure 6a, inhibits the sudden change 
in current presented by rapid transition times. This initially 
appears as a large. impedance mismatch which makes the 
reflection coefficient (p) approach + 1 instantaneously. The 
effect of p is to speed the slew rate on the fall time and 
extend the overshoot on the rising edge. The different re- 
sponse of the two edges is due to the active pull down and 
the passive pull up. 
2.5V 
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FIGURE 8a. Bench Test Jig Waveform 


_ The second reason is the path inductance and line delay of 


the backplane, daughter, board,‘ and the termination 
scheme. The transmitter pull down transistor is turned on 


~ with a very large base current needed to supply 80 mA col- 


lector current. This collector current is supplied by the termi- 
nation resistor which is located at some electrical distance 
(backplane and daughter board paths) from the transistor. 
As the transistor experiences a hard turn on, it initially sees 


_. what appears to be an open circuit. The momentary open 


circuit. causes the overshoot and fast falling edge. This is 
due to the inductance and delay of the signal path prevent- 
ing the current from changing immediately at the collector of 


' the transistor. This inductance limits the driver slew rate 


control at the transceiver pin. Bench testing of the same 
part shows a fall time 1 ns longer than the daughter board 
fall time. The difference in fall times under test conditions 
are due to load proximity and availability of almost instanta- 
neous current on the test jig. The rise time is much slower 


. because it is a passive pull up and is controlled by the expo- 


nentially decaying current due to the inductance. 
Another look at the waveform will show that there is an 


‘increase in voltage just prior to the high to low transition. 





This is also due to the large, fast voltage change at the base 
to the output transistor. The voltage step is coupled through 
from the base to the collector by the Miller capacitance. 
This small spike only shows up in the backplane environ- 
ment for the same reasons as already explained. 











IMPEDANCE MISMATCHES 


The next probe is at the inter-layer via points of the signal 
line and ground line. Labeled point 55 in Figure 7. These 
vias present a relatively large capacitive impedance to the 
signal. The capacitance of the plated through hole (PTH) via 
has been estimated as high as 1.1 pF by Hybricon down to 
0.75 pF by the Futurebus+ Expert Team. This is also the 
point at which the microstrip trace changes to a stripline 
trace. The capacitance of a PCB track varies directly with 
track length and width, but inversely with the dielectric thick- 
ness. Typically, this corresponds to about a 50% increase in 
capacitance from outer to inner layer for an eight layer 
board. As seen by the TDR investigation, the path imped- 
ance drops from 752 to 602 at this point, Figure 6. Thus, 
the stripline circuit element, T(50,55), can be characterized 
by an increase in the capacitance per unit length. 


Figure 9 illustrates the damping of the overshoot and under- 
shoot that is caused by the capacitive reactance. The fall 
time is increased by the capacitance. This can be intuitively 
understood by considering the capacitive impedance break 
of Figure 4c. This has a counter balance affect on the path 
inductance so the needed current is available. Initially, the 
load appears as a short circuit because the capacitance will 
not accept an immediate change in the voltage. The p at the 
impedance mismatch then initially approaches —1. The 
quick charging of the capacitance pulls the slew rate out of 
a nose dive and limits the undershoot. The rise time shows 
a slight increase, but the resolution of the scope comes into 
play for times less than 150 pico seconds. 


The third major impedance mismatch of the signal path oc- 
curs at the PTH to Metral connector solder point. Point 50 in 
Figure 1. The ground reference for the low inductance tip is 
the solder point for an adjacent connector ground pin. The 
circuit element for the connector is modeled by T(5,50). A 
SPICE model is provided by DuPont, the connector manu- 
facturer. The TDR waveform clearly shows the capacitance 
of the solder filled PTH lowering the impedance to 500, 
Figure 6. The same figure then shows the connector wire 
presents an inductive impedance increase for the signal. 
Figure 10 shows considerable overshoot damping. It also 
shows an increase in rise time and fall time. The multiple 
discontinuities to this point have degraded the initial rise 
time of the signal so that the overall effect is that of line 
loss. The passive pull up accentuates only the resistive por- 
tion of the impedance rather then the reactive. 


Notice the reflection that is well defined at the bottom of the 
falling edge. A closer examination of Figure 8 shows that 
this same reflection is present in an attenuated form. The 
peak of this reflection is about 2 ns from the point where the 
signal crosses into an undershoot state. The delay per unit 
length, tpg, of the unloaded backplane depends on the rela- 
tive magnetic permeability, 2,, the relative dielectric permit- 
tivity, e,, and the speed of light, c. 


With e, = 4.7 and p, = 0.99, then tpg = 0.18 ns/in. So a 
round trip of 10 in., slot 5 to slot 0 and back, will be a delay 
of about 1.8 ns. This is almost exactly the delay of the re- 
flected pulse at the connector solder point in Figure 10. The 
delay is measured from the falling edge tangent line. The 
period of this pulse is about 1.5 ns which is a frequency of 
667 MHz. 
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FIGURE 10 


ENTERING THE BACKPLANE 


After the connector, the signal reaches the backplane envi- 
ronment. The signal has been transformed by the daughter 
board path. Besides the impedance factors, the skin effect 
losses have rounded top and bottom portions of the edges. 
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The probe points are at the solder points of the Metral con- 
nectors to the backplane PTH. The waveform in Figure 17 
was obtained at the slot where the board is inserted, just on 
the backplane side of the connector from the previous fig- 
ure. The connector increases the fall time by 500 ps and 
damps the overshoot. The increase in fall time here appears 
to be a result of the reflected pulse increasing in amplitude. 
As the incident wave propagates further down the back- 
plane the same damping of overshoot and increase in tran- 
sition times occurs. The backplane characteristics are de- 
pendent on the loading that is present in the form of insert- 
ed boards with transceivers. 
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THE LOADED BACKPLANE 


The distributed capacitive loading of the backplane has sig- 
nificant effects on the signal. ‘The position of the loads with 
respect to the driving board will determine how the reflec- 
tions add to degrade the signal. The worst case is when the 
reflections cut into the noise margin; i.e., the reflections that 
are positive going on the low output and negative going on 
the high output. The investigative results show that reflec- 
tions in the high state never go below the 2.1V level by more 
than 50 mV. The problem on the high end occurs when the 
bus is fully loaded. At 20 MHz and fully loaded, ‘the rising 
edge becomes rounded, Figure 72. 


The worst bite into the noise margin was found in the case 
of 2 loads, 12 pF each, in specific slots on the backplane. 
The driver in slot 5 and the loads in slot 6 and 0 caused 
sustained ringing with a peak amplitude of 200 mV into the 
noise margin low. The case is shown in Figure 73. It should 
be noted that the period of the ringing in Figure 73 is about 
2 ns. This corresponds to a frequency of 500 MHz. This 
presents a demand on test equipment to pick up these high 
frequency signals. 
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FIGURE 12. Backolane Probed at Driver = Slot 5, 
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FIGURE 13. Backplane Probed at Driver = Slot 5, 
12 pF Loads In Slots 0 and 6 


GIGA HERTZ BANDWIDTH 


A 400 MHz probe and scope would not pick up all of the 
frequency components of this ringing. Because of the high 
frequency components that comprise this signal, all of the 
measurements done by National Semiconductor on the 
Futurebus+ chip set are obtained by using the Tektronix 








P6204 FET probe and 11A72 amplifier mounted in the 
11403 digitizing oscilloscope. This combination has a band- 
width of 1 GHz. 


Figure 14 is included to show how a single load of 12 pF will 
cause different reflections depending on where it is inserted 
with relation to the driving transceiver. The line delay is evi- 
dent when the reflection from the adjacent load appears 
before the reflection from the far end load. The different 
loading positions will determine the waveform shape and 
how it will encroach on the noise margin. 
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FIGURE 14. Backplane Probed at Driver = Slot 5 


WHY ALL THE DIFFERENT GROUNDS? 


There are three different types of gound pins on the Nation- 
al Semiconductor Futurebus+ Chip Set. They are the logic 
ground (GND), the BTL grounds (BOGND-B8GND) and the 
bandgap reference ground for receiver threshold (QGND). 
All of these ground reference pins are isolated inside of the 
chip to limit the interference from high current switching 
transients. Outside the chip, the bandgap reference ground 
should be connected to the backplane ground through a 
quiet channel. The isolation purpose is so the receiver input 
threshold will follow the same reference as the signals com- 
ing off the backplane. The other grounds should be tied to 
the board ground plane to prevent ground loop currents in- 
side the chip. 


FUTUREBUS+ TRANSCEIVER GROUND BOUNCE 


A single transceiver can have up to 9 BTL channels switch- 
ing at the same time. If each channel sinks 80 mA, there is 
substantial current switching taking place. The combination 
of the ground lead inductance and finite resistance of the 
current return paths cause voltage drops and rises to occur 
along this path that are proportional to the changing current. 


V =L(di/dt) 
where V = amplitude of the ground bounce 
L = inherent inductance of signal and ground trace 
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The DS3886 Latched Data Transceiver mounted in the Hy- 
bricon proto board was used to investigate the amount of 
ground shift that is experienced in the Futurebus+ environ- 
ment. 


Eight channels are connected to the same input so that they 
are switching simultaneously. The ninth channel, B3 (locat- 
ed between the other eight), is driven to the asserted state 
and used as a reference. Six other data transceivers were 
also on the board and allowed to switch at random (open 
driver inputs). The Futurebus+ connector pin layout uses 1 
of every 3 pins as a ground pin. The Hybricon board links all 
these pins to the board ground plane as they enter through 
the Metral connector. The transceiver BTL ground pins are 


-mounted to the solder pad and then traverse a microstrip 


track to a PTH via to make ground plane contact. The mi- 
crostrip adds inductance to the ground path but is neces- 
sary for even heating to solder the chip package to the ther- 
mally isolated pad. 


PROBING THE GROUND 


The backplane ground plane is used as a reference to in- 
vestigate all of the ground differences in the circuit. It is 
accessed through a ground tab connector on the Metral 
power connector module. Figure 15 shows the idle back- 
plane noise at the top of the picture. The GHz probe with a 
short, low inductance alligator clip ground was used to 
probe two of the empty slot ground tabs. There was no 
transceiver activity for this situation. The second from the 
top waveform is the same probe ‘position only eight trans- 
ceiver channels are now switching. Large disturbances in 
the signal occur at the time that eight channels are all going 
from high to low, the time of substantial active current 
change. Notice how the low to high transition does not cre- 
ate the same sort of voltage spike on the ground signal. 
This is because the collapsing current doesn’t have a large 
di/dt. 


The same backplane ground reference was used for all of 
the measurements in Figure 15. The third pattern was ob- 
tained probing the daughter board ground plane close to the 
Metral connector between the switching transceiver and the 
backplane. The disturbances are muted in this case by the 
bypass capacitors of the board. The board is decoupled by 
4-180 pF and 14-0.1 uF capacitors. The next waveform is 
from the same ground plane but it is probed at the via that 
connects the microstrip from the transceiver BTL ground pin 
to the board ground plane. This waveform is a slightly atten- 
uated version of the waveform seen on the non switching 
ground pin. This is because the waveform seen at the 
B3GND pin is coming from the board ground plane! The 
inductance of the microstrip and the lead frame inside the 
package increase the overshoot and.the undershoot of the 
ground bounce. The worst ground disturbance is measured 
at one of the switching channel BTL ground pins. This is as 
expected from interior transceiver noise caused by the hard 
turn on of the output transistor creating very rapid build and 
collapse of current. . és 
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FIGURE 15 


CROSSTALK IN THE FUTUREBUS+ ENVIRONMENT 


The crosstalk problem has received a lot of attention. There 
is the potential for significant forward and backward cross- 
talk due to the high speed signals, multiple transmission 
path media, and the density of the signal lines. These are 
the simplified equations relating the contributing factors. . 


Mbkwd = (Va/t) (4 /2t 2) (CoZ + Le/Z) 
= backward coupled voltage to victim line 
Virwd = (Va/t) (2/2) (CoZ — Lo/Z) 
_ = forward coupled voltage to victim line 
= aggressor signal amplitude 
= aggressor signal transition time 

line length 

= line delay 

line impedance | . 

-capacitive coupling due to electric field 

inductive coupling due to magnetic field 
Both types of crosstalk are directly proportional to the am- 
plitude, and inversely proportional to the transition times of 
the aggressor signal. The capacitive and inductive coupling 
affect both types of crosstalk. In backward crosstalk they 
add together and are multiplied by the aggressor amplitude 
to give a same polarity pulse to the victim. In forward cross- 
talk, the quantity (C¢Z — L¢/Z) is multiplied by the aggres- 
sor amplitude to give a pulse of either polarity depending on 
the relative size of the coupled reactances. The connector 
does present a special problem due to the open wire config- 
uration. The inherent inductance of the open wires and the 
proximity in the Metral connector are favorable situations for 
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crosstalk. Not modeled in the above equations but still a 
factor is the signal wave velocity differences. Forward 
crosstalk also results from velocity differences of an aggres- 
sor signal due to the conductive medium contacting sub- 
stances of different dielectric constants. The microstrip line 
is such a medium that contacts both air and epoxy glass. 
This creates an energy pulse that will couple electrostatical- 
ly to the victim. For these reasons, crosstalk was investigat- 
ed in two different ways. 
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FIGURE 16. Module B, Section 3, Used In Crosstalk 
Measurements. The Victim Line Is Labeled B-b-16 


Futurebus+ standards committees set up the pin designa- 
tions on the Metral connector so that there is one ground 
pin for every 2 signal carrying pins. The worst case then is 
the situation where 1 signal pin can be surrounded by 5 
signal pins and 3 ground pins as in Figure 76, The’ Expert 
Team tested crosstalk using a switching line as victim and 
measured the difference between 0 and 5 aggressors at a 
receiving module. Figure 17 shows avese same tests for 
DS3886. : 


The driver module is located in vate 7 and two receiver mod- 
ules are in slots 0 and 9. As mentioned in the section on 
reflections, this is the worst configuration for cutting into 








the noise margin. It is also a long length for the parallel 
backplane tracks to cross couple. The signal line ST2 was 
used as the victim and STO-ST7 as the aggressors. Figure 
17 shows the falling edges at the driver and receiver pins for 
the two conditions, only the victim switching and then all 
aggressors and the victim switching. The largest amount of 
induced voltage onto the victim line is 50 mV. This is the 
same result as the Expert Team. 
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FIGURE 17 
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FIGURE 18. Victim Is Only Asserted, 
8 Aggressor Channels Switching 
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Figure 18 shows results of a different way of investigating 
the crosstalk than the Futurebus+ Expert Team method. 
The victim line was held in the asserted state while 8 ag- 
gressor lines were switching. The top waveform is the ag- 
gressor signal. The three lower waveforms are the victim 
signal probed at daughter board impedance points. The fig- 
ure shows that the victim experiences a 100 mV pulse into 
the noise margin at the high to low transition of all the ag- 
gressors. This case is measured on the backplane at the 
same slot as the driver. A demonstration of the high induc- 
tance of the Metral connector is the inversion of the induced 
signal through the connector. The inductance of the con- 
nector is large enough to give the forward crosstalk an in- 
verted pulse at this point. In an actual data transmission, the 
crosstalk concern would be at the input to the receiving 
transceiver. The slowing of the edge rates by the time they 
reach a receiver on another board will further reduce the 
magnitude of the crosstalk. Figure 19 shows the signal at 
the same receiver input pin with no aggressors and with 8. 
The coupled voltage intrusion to the noise margin is 85 mV. 
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FIGURE 19. Crosstalk Voltage at Receiver with 8 
Aggressor Lines Compared to 0 Aggressors 
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CONCLUSION 


The Futurebus+ environment presents impedance mis- 
matches to the high speed data signals. These circum- 
stances make the measurement of the signals dependent 
on where they are measured. The fast edge rates of the 
signals have high frequency components that compose a 
large part of the waveform and can not be ignored. For 
these reasons, National Semiconductor uses 1000 MHz 
bandwidth test equipment, and specially designed low im- 
pedance test jigs for all of the data sheet specifications. 


The placement of modules in a partially loaded backplane is 
crucial to the magnitude of the ringing. The equal distribu- 
tion of the modules in the backplane appears to be the best 
condition for the lowest magnitude ringing. 


Figure 20a shows the noise margins for BTL. Figure 20b 
shows the allocation of the noise margin for a fully loaded 
backplane and partially loaded in Figure 20c according to 
the Futurebus+ Expert Team. They have done extensive 
simulations that are reported in the Interim Report present- 
ed on September 14, 1990. This investigation of the reflec- 
tions and crosstalk will be compared to their findings. 


Figura 17 shows the combination of worst case crosstalk 
and reflections that were found in this investigation. The 
crosstalk added to the reflections to cut into the noise mar- 
gin low by 100 mV. The 100 mV intrusion is deduced from 
the fact that the incident edge has a distinct edge at the 
1.2V level. This is within the allowed 170 mV range in the 
Expert Team analysis of the partially loaded backplane, Fig- 
ure 20c. This investigation also showed that the fully loaded 


backplane produced lower magnitude reflections than the 
partially loaded backplane. The measurements collected 
here support the Expert Teams allowance of only 140 mV 
for reflections and crosstalk in the fully loaded backplane, 
Figure 20b. 


The National Semiconductor DS3886 Latched Data Trans- 
ceiver maintained signal integrity in the Futurebus+ Back- 
plane environment under severe operating conditions. 
Worst case situations of crosstalk, stub length and ground 
bounce combined with a transmission speed of 40 MBaud 
were used to test the DS3886 in real backplane operating 
conditions. The incident edge of the BTL signal consistently 
crossed the receiver threshold without a problem. 
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Futurebus+ Wired-OR ~— . 
Glitch Effects and Filter __ 


INTRODUCTION 


Futurebus + addresses the needs a the high-end user we 
requires more bus performance than what has previously 


existed. In order to optimize bus performance, the back- . 


plane bandwidth’ has' been increased to where the’ back- 
plane line delays are In‘the same order of magnitude as the 
transfer periods. At this level, the backplane can no longer 
be treated as lumped loads but must be modeled as distrib- 
uted loads which is in the realm of transmission lines. .De- 
signers must now deal with transmission line effects and be 
aware of glitches that occur when performing wired-OR 
functions. As the name implies, the wired- OR glitch’ occurs 
on lines that perform wired-OR logic. Wired-OR logic is im- 
plemented by connecting open-collector drivers in’ parallel 
and tying their collectors to a resistor pull-up (Figure 7). Na- 
tional Semiconductor’s Futurebus +, Handshake Transceiv- 
er addresses this concern by incorporating a programmable 
low pass filter into the receiver. It provides optimum noise 
rejection while maintaining high bus through-put. . 





TL/F/11133-1 
FIGURE 1 


BTL (Backplane Transceiver Logic) is the driving technology 
behind the Futurebus+ physical layer. Driver outputs are 
open-collector with a series Schottky diode. The additional 
diode on BTL drivers isolates the normally large collector 
capacitance associated with the output transistor from the 


iV, 


National Semiconductor 
Application Note 744. ; 
Joel Martinez/Stephen Kempainen 


bus thus reducing bus loading. BTL is used on all the bus 
lines in a Futurebus+ backplane. Termination of the bus is 
done at both ends as shown in Figure 2. All Futurebus + 
lines are connected in a wired-OR fashion, however, only a 
subset of these lines actually perform. the wired-OR logic. 
These lines are the handshake, status, capability and arbi- 
tration lines. The critical timing lines used in handshaking 
must have wired-OR glitch filters to maintain signal integrity. 
The lines requiring glitch filtering are AK*, Al*, DK*, DI’, 
AP*, AQ*, AR*, and RE*. 

In the wired-OR configuration, the glitch abeoried on the 
backplane is caused by the release of one or. more drivers 
on the bus while others remain asserted. The resulting posi- 
tive voltage pulse is the glitch characteristic that could cross 
the receiver threshold and degrade .signal integrity. The 
transmission line effect, enhanced by the fast transition 
times and transmission line propagation delay, dictates how. 
the wave reflections will affect the data signal. If the rise and 
fall times were longer. than the line delays, the reflections 
would be included (shadowed) in these transition portions of 
the signal. Then the bus would not exhibit transmission line 
effects. However, the Futurebus+ transition times on the 
backplane can be one fourth to one fifth of the line delay. A 
transition at one end of the backplane takes some time be- 
fore it reaches the other end and voltage levels will vary 


significantly, due to reflections, before equilibrium. 


Low to High Transition of Open 
Collector Bus Driver 


First the low to high transition of a single driver releasing the 
bus will be studied. The same characteristics are involved 
for the wired-OR glitch as will be seen later. Referring to 
Figure 3, what happens when Q1 releases? 


V 
TL/F/11133-2 


FIGURE 2 
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my 


FIGURE 3 


t< to; at is on (asserted) and maintains a Vo level on the 
-. bus... ane. Ve Teh a 
 Zdriver. . 
V, = Vv: ee 
OL” "T Zdriver +’ (Ry/2) 
’ where Zdriver = driver output impedance ~ 
t = to; Q1 releases and a low to high wave front propa- 
gates from slot 0 towards slot 1. The current which 
was previously sunk by Q1 now gets injected back 
into the line. The driver sees an impedance of the 
termination resistance in parallel with the line imped- 
ance. The amplitude of the signal propagating down 


ae) 


the line is described by the following equation: 
VFINAL = VoL + TloL *(Ry//Zo)] 


Vr — Vor, 

<a es / ' 
Rye (Ri//Zo’) 

For Rt = Zo’, where Zo’ is the unloaded line imped- 

ance. 

VFINAL = Vo. + Vt — VoL 


= Voi + (1.a) 





ty 


‘VFINAL © 
Von 
VFINAL 


Vor 
TL/F/11133-3 


If the driver was located in slots 1 to 8 then the equation 
would be; oe ors ie 


VFINAL = Voy + EY + (Zy'//Z0') (1) 
©’ Ryf2 

t = ty; The signal reaches slot 9. For Ri = Zo’, all the ener- 

gy is absorbed at slot 9 by the termination and the 

bus will be at equilibrium. For Ry # Zo’ then second- 

ary reflections will occur until the reflections settle. 


Figure 4 shows the actual waveform from a 10 slot back- 
plane with 1 in. pitch and 390 termination resistors. The 3 
waveforms were obtained by probing the backplane at the 
solder points of the board connectors. In this case there 


. were two boards inserted into the backplane, slots 0 and 9. 


The driver in slot 0 is switching while the other in slot 9 is 
off. The propagation delay of the line, tpd, is then defined as 
ty — to. This is plainly illustrated by the delay in the wave- 
form probed at slot 0 and at slot 9. The tpd = 3 ns in this 
arrangement. , 


5 ns/div 
FIGURE 4 
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Wired-OR Glitch 


As shown in Figure 5, things become more complicated by 
adding another driver at the opposite end of the bus. Initial- 
ly, both drivers are asserted. Assuming they share the cur- 
rent from the termination equally, the Vo will be less than 
Vo for a single driver. Vo is also influenced by the fact that 
the driver impedance increases with reduced current 
through the transistor. When Q1 releases, a glitch occurs at 
the drivers bus slot with a pulse-width equal to 2 times the 
line delay. The glitch amplitude is dependent on the amount 
of current that was sunk by the driver prior to releasing the 
line. So the more drivers that release the line simultaneous- 
ly, the greater the amplitude of the glitch. 


t < tg Both Q1 and Q9 are on keeping the bus voltage low. . 


Note that VO results from the resistor divider between 
the parallel driver output impedance and the parallel 
termination resistance. V2 is slightly higher because 
only one driver is on and the bus voltage is then just 
the resistor divider between a single driver output im- 


pedance and the two termination resistors in parallel. © 


t = to Q1 turns off and transitions into a high impedance 
state, a low to high wave front propagates down the 
bus towards slot 9. 


yon 1 WTO. ay /0% 
v1 : ara Ae * Pu//2o (2.1) 


FIGURE 5 
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For Ry = Zo’ 


v1 = Vo + 5 (Vr — VO) 


1 2 
= 5 (Vr + Vo) (2.2) 
The glitch reaches slot 9 and the reflection at slot 9 
is negative because the output impedance of the 
driver is small compared to the termination resistor 
and backplane impedance. 


= 1 (V7 — VO) 
v2=V1 ae Rye 
R,//Zdriver — Zo’ 
R;//Zdriver + Zo 


The reflected wave reaches slot 0. It is important to 
point out that the output of Q1 is in a high impedance 
state when turned off. Therefore, the mismatch at 
slot 0 is only due to the backplane impedance and 
termination. For Ry = Zo’, all the energy is absorbed 
at slot 0 by the termination and the bus will be at 
‘ equilibrium. When Ry * Zo’, then secondary reflec- 
tions will occur and will continue until the reflections 
settle to the termination voltage. . 
The pulse width at the end of the backplane where the driv- 
er is still asserted is as wide as the propagation delay of the 
bus. Since the reflection must return to the released driver 
end, the pulse width there will be 2 tpd, where tpd = (ty — 
to) = (te — th). ee 


*Rr//Zo' * p 


where p = (negative number) 


TL/F/11133-4 





Wired-OR Glitch Calculation for Futurebus + 


To calculate the wired-OR glitch for a Futurebus+ back- 
plane the following assumptions are used; 


i all ll 
Connector and Vias 

Zo" [31a | Fully LoadedBackplane | 

}R_— | 3an | Termination Resistor | 

5 


R,//Zdriver 
| Zdriver [50 Driver Series Resistance 


Vdriver 0.7V Driver on Voltage in Series with 
the Resistance 


0n 
3n 
n 


V 
V 


Zo’ 

Zo” 
T Termination Voltage 
TH i 

pd 


1.47V to | Receiver Input Threshold 
1.62V 
t 1.8ns Unloaded, 10 Slot by 1 in. Pitch 
Backplane . 


Same Backplane Fully Loaded 


For drivers at each end (Figure 5) and assuming an Unload- 
ed condition we have; 


: Zdriver 
VO = Vdriver — (V7 — Vdriver) * re Tap 
- i += 
3 Zdriver 3 Rt 
VO = 0.52V 
From equation (2.1) 


1 (Vr — VO) 
= +--+ ———- 
V1 = VO 2° Rye *Ri//Zo 
V1 = 1.3V 


When the reflected wave hits the mismatch at slot 9, a neg- 
ative reflection adds to V1. 


1 Driver on 
2 Drivers on 


re 
fAv/2o" [ison | 
pia 


R;//Zdriver — Zo’ 
V2=Vi¢cpl*y,l pl = 
poe Wx" PY Ril /Zdriver + Zo’ 


1 (V7 — VO) 
V: 1 =—* 
| IB Rie 
When this wave front reaches slot 0, another negative re- 
flection adds to V2. 


= 0.62V *Rr//Zo' 


_ Ar - Zo’ 
Ry + Zo’ 
= 0.78V Vx2 = Vxt * p2 


Subsequent reflections will be smaller and smaller until 
equilibrium is reached on the line. 

The glitch has a maximum amplitude of 1.3V for two drivers 
sharing the bus current equally, which is below the receiver 
threshold of 1.47V. This isn’t enough amplitude to false trig- 
ger the receiver and thus data corruption will not occur. The 
glitch also has a. maximum pulse width equal to 2 tpd or 
3.6 ns. If Q1 was sinking most of the current, then the result- 
ing glitch will have a greater amplitude than that calculated, 
but the pulse width will remain the same. The greater ampli- 
tude may cross the receiver threshold and cause false trig- 
gering. The purpose of the glitch filter on the DS3884 is to 
filter any glitch that crosses the receiver threshold and 
thereby prevent false triggering. Since the glitch width is 
independent of amplitude, a filter can be set to reject certain 
duration glitches. , 

Figure 6 shows actual waveforms from the 10 slot back- 
plane. The drivers are mounted in the end slots and Ry = 
392. The Vdriver (1 driver on) level is 685 mV and VO (2 
drivers on) is 545 mV. The switching driver is shown without 


V3 =V2+ p2*Vx2 + p2 


the other driver asserted, waveform A in Figure 6. Then the - 


wired-OR glitch is shown at the end slots with one driver 
switching and the other holding the asserted level, wave- 
forms B and C. As predicted by the model, the amplitude 
and pulse width of the glitch is greatest at the driver slot that 
is releasing the line. The maximum amplitude of the glitch is 
1.25V. The propagation delay of the backplane with 2 
boards inserted was shown in Figure 4 to be 3 ns. The mod- 
el predicted the pulse width to be twice this delay, but it is 
shown to be 2.33 times the delay at 50% of the amplitude. 
This is because the model does not take into account the 


TL/F/11133-6 


FIGURE 6 
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wave dispersion effects of the backplane which filter the 
high frequency components and round the signal corners. 
Since the glitch amplitude will never equal V7 as indicated 
by equation (2.1), the glitch pulse width at the receiver 
threshold will always be less than the 50% amplitude pulse 
width. Two times the measured backplane propagation de- 
lay is the worst case width that will be seen at the receiver 
threshold. 


Theory states that glitch width is only dependent on the bus 
propagation delay. Figure 7 and 8 are included to demon- 
strate this theory in the backplane application. Figure 7 
shows the glitch for a 1 MHz signal. The pulse width is the 
same as that in Figure 6 which has a 20 MHz signal. Figure 
& is the same situation as Figure 6 except that the back- 
plane slots between 0 and 9 are loaded with 10 pF to 12 pF 


each. This increases the propagation delay of the’ back- 
_ plane. The width of the pulse is 10.7 ns. Using the fully 


loaded backplane tpd of 4.4 ns, this pulse width is 2.43 
times the propagation delay. This figure correlates well with 


_the previous partially loaded glitch width. The amplitude is 
noticeably less when the backplane is fully loaded due to | 


the decreased impedance seen by the driver. 


The simultaneous release of the bus line by more than one 
driver at a time will increase the amplitude of the glitch but 


: the width still depends on the propagation delay of the bus. 


The current of more than one driver injected into the line 
directly affects the amplitude of the pulse. Figure 9 shows 
the glitch when 2 drivers release the line simultaneously and 
1 holds the line asserted. The releasing drivers are in slots 0 
and 3, and the hold driver is in slot 9. The glitch amplitude of 


__ 1.81V will cause a false trigger of receivers on the line. The 


pulse width of the glitch at the receiver threshold low is 6 ns, 
about 2 tpd. The 50% of amplitude pulse width. is slightly 


_ larger than the case of 2 drivers on the bus, but this is 


explained by the additional load capacitance of the third 


driver which increases the line delay. 


WIRED-OR FILTER 


The worst case glitch that can occur on the bus will have a 
pulse width equal to the round trip delay of the backplane. 


- The filter must reject glitch pulses which are equal to and 


less than the worst case round trip bus delay, 2 tpd. Since 
the line delay is dependent on the length and the loading of 
the backplane, the simplest way to determine the worst 


case delay is by measuring the line delay of a fully populat-- 


ed backplane. Once the worst case delay is determined, the 
receivers should provide a filter that will reject the glitch and 
allow signals to pass through with minimum delay. 


The DS3884 Handshake Transceiver which is part of Na- 
tional’s Futurebus+ chip set has a built in glitch filter. The 
filter can be tailored to a specific backplane delay to mini- 
mize timing delays. Four different settings—(5 ns, 10 ns, 
15 ns and 25 ns) are available via the pulse select pins— 
PS1 and PS2. These settings can be fine tuned by varying 
the resistor to ground at pin REXT. For example, if the round 
trip delay of the backplane is 8 ns, then the filter setting 
should be rounded-off to the higher setting which is 10 ns. 
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FIGURE 9 








This setting will reject glitches with pulse widths of 10 ns 
and less. The maximum propagation delay from the trans- 
ceiver bus input, Bn, to the filtered receiver output, FRn, for 
the receiver high to low transition will be 22.5 ns at this 
setting. Figure 10 shows three waveforms from the DS3884 
operating in slot 0 of the same backplane configuration as 
Figure 9. Waveform B1 results from the same 2 drivers re- 
leasing the line simultaneously as Waveform B slot 0 in Fig- 
ure 9. The lower signal amplitude is due to probing directly 
at the receiver input pin rather than the backplane solder 
point as in Figure 9. R1 and FR1 are the waveforms from 


5 ns/div 


TL/F/11133-10 


FIGURE 10 


DS3884, channel! 1, for the receiver and filtered receiver 
outputs respectively. PS1 and PS2 are both set to OV to 
obtain a glitch rejection of 5 ns and less. Waveform FR1 
clearly rejects the false triggering of the glitch, which is 
about 3 ns wide at the 1.5V receiver threshold. Figure 77 
shows the propagation delays for B1 to R1 and FR1 for both 
the high to low and low to high transitions at the 5 ns glitch 
rejection setting. The tpy, is extended from 5 ns to 10 ns for 
the filtered output. The ringing on the receiver output signals 
results from wire wrap board frequency response limits. 


5ns/div 


: 1 TL/F/11133-11 
FIGURE 11 


The wired-OR glitch is inherent in wired-OR busses and will exist in a high speed transmission line environment. However, it 
is comforting to know that it is a well understood phenomena and there are ways of maintaining signal integrity through the 
use of filters. oe 
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DS3885 Arbitration 
Transceiver 2% 


INTRODUCTION 


. Today's digital systems with their higher clock speeds and 


data throughput, must have higher transfer rates to keep the 
processors running at top speed. With these types of cir- 
cuits, it is essential to have high performance bus transceiv- 
ers which tie together everything on the bus. Without spe- 
cialized bus interface transceivers, board designers must 
dedicate a substantial amount of pc-board real estate to the 
bus interface. Typically, these devices implemented with 
discrete ICs or PALs can take up to 20% to 30% of the 
available real estate. Also, interrupt structure, arbitration 
scheme, and burst-data transfer features result in added in- 
terface complexity. 

The trend toward distributed intelligence increases the need 
to place more functions on a single board. Therefore, inter- 
face ICs play an important role, especially in the design of 
boards for high performance buses such as Futurebus+. 
The purpose of this Application Note is to highlight the im- 
portant features of the DS3885 Arbitration Transceiver. 


DS3885 ARBITRATION TRANSCEIVER 


The DS3885 Arbitration Transceiver is one of the 5 devices 
in the chipset for Futurebus+. Other devices include; the 
DS3883 BTL 9-bit Data Transceiver, DS3884 Handshake 
Transceiver, DS3886 BTL Latching Transceiver, and the 
DS3875 Arbitration Controller, which supports all modes of 
the Futurebus+ distributed arbitration protocol (Figure 1). 
The DS3885 Arbitration transceiver conforms to the IEEE 
P896 Futurebus+ specifications for. the distributed arbitra- 
tion. However, it can also be used to support messaging 
function in the central arbitration scheme. It allows several 
modules to compete using the same distributed arbitration 
bus. The DS3885 integrates this function within a bus trans- 
ceiver to reduce part count and competition delay. 


' The DS3885 supports live insertion as required by the Fu- 


turebus+ modules. Futurebus+ specifications provide sup- 
port for those applications requiring dynamic reconfiguration 
and fault tolerance. Thus, the Futurebus+ protocol sup- 
ports the insertion or replacement of any module on the bus 


083875 
Arbitration Controller 


DSXXXX 
Protocol 


National Semiconductor 
Application Note 742: 
Chai Vaidya, IPG Applications - 


without the need for power-down on the backplane. Howev- 
er, it is expected that the. system software must support 
diagnostics to determine if any module is faulty. If a faulty 
module is detected, the software should disable this module 
and pass this information to the maintenance logic. The pin 
LI (Live Insertion) of this device should be connected to the 
live insertion power connector. If the live insertion is not 
supported, LI (pin 2) should be tied to Vcc. 

As system bus such as Futurebus+ gets faster and wider, 
the interfacing transceivers must supply clean signals with 
controlled rise and fall times, and a very low skew. The mini- 
mum and maximum rise and fall times of the on-chip drivers 
on the DS3885 are 2 ns and 4 ns respectively. These con- 
trolled rise and fall times help reduce crosstalk on the bus. 
In order to reduce the loading on the bus, a Schottky diode 
is added in series with an open-collector driver output. Due 
to this, the capacitance of the driver transistor is isolated by 
the small reverse-biased capacitance of the Schottky diode 
in the non-transmitting state. With the Schottky diode ca- 
pacitance of 2 pF, the total loading capacitance of this de- 
vice is under 5 pF. 


Figure 2a and 2b are block and logic diagrams of the 
DS3885 device. It has an input latch for latching the arbitra- 
tion number and a driver to place this number on the bus 
backplane. The DS3885 generates win/lose signal depend- 
ing on the outcome of the competition. The worst case de- 
lay from COMPETE to WIN is 75 ns maximum. The WIN- 
/LOSE signal can also be used by any module not partici- 
pating in the competition to determine whether its competi- 
tion number is greater than the number of the winning mod- 
ule. When all signals ABO to AB7 are asserted the device 
will inform the Arbitration Controller of this condition by as- 
serting the signal AA. 

In addition to receiving and transmitting signals on Future- 
bus, the device contains arbitration comparison and parity 
checking logic. By combining the BTL and the arbitration 
logic, the DS3885 device reduces the logic propagation de- 
lay for arbitration competition. 


32/64/128/256-Bit Data Path 


Controller 
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Handshake Data 
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FIGURE 1. IEEE 896 Compatible Futurebus+ Chipset 
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FIGURE 2a. Block Diagram of DS3885 


TL/F/11130-10 


COMPS 


CN7 





| TL/F/11130-1 
FIGURE 2b. Logic Diagram of DS3885 
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The following section describes the mechanism involved in 
the process of arbitration on the Futurebus+. It. may be 
useful for those designing systems using National’s 
Futurebus+ chipset including the Arbitration Controller. 


FUTUREBUS+ ARBITRATION 
Futurebus+ provides a distributed arbitration scheme to se- 


lect mastership of the bus for one module at a time. The - 


equivalent parallel contention logic (shown in Figure 3) is 
used to determine which module has the highest arbitration 
number. This arbitration competition for control of the bus 
takes place in parallel with the data transmission process. 
Each module is assigned a unique arbitration number, which 
is used to resolve the arbitration competition. 


The Futurebus+ arbitration protocol uses 14 lines Sane 


backplane. Due to the limitations of the number of bus lines 
used for arbitration, some competition numbers require two 
passes of the control acquisition cycle. Each pass of the 
control acquisition cycle drives half of the given arbitration 


number. In addition to the 9-bit arbitration bus, there are | 


three protocol handshake lines and two arbitration condition 
lines which define the protocol of the operation of the arbi- 
tration protocol. The three handshake lines are; AP*, AQ* 


and AR*. These lines control the arbitration process, in 


which each module competes, checks for errors and in case 
of the winner, wait until the current master has finished its 
tenure. They allow the modules to step through the various 
phases of arbitration, and adapt the speed of the protocol to 
the slowest participating module. These three handshake 


signals make use of wired-OR characteristic of BTL to pro- _: 


vide six phases that can be used to describe the arbitration 
sequence. There are two additional condition signals; ACO* 
and AC1*. ACO* is used to signal arbitration cycle errors. 
This helps to determine the arbitration settling time more 
accurately. AC1* can be used by any module to prevent the 


exchange of bus mastership on the current arbitration cycle. . 


The DP3885 receives the arbitration number from the mod- 
ule and compares it to the number on the bus to determine 
if the module has won bus tenure. After a certain settling 
time, the module with the highest competition number will 


find that its number matches the number remaining ‘on the’ ° 


bus; therefore, this module is a winner. 


MODULE 


BUS 
ABG* 


The actual arbitration competition takes place on a 9-bit ar- 
bitration bus. Each competing Futurebus+ module latches 
its competition number into its DS3885 Transceiver. All 
modules apply: this number through the parallel contention 
arbitration logic onto the open collector arbitration lines, 
AB(7 ... 0,P); where P is the odd parity bit (LSB). The arbi- 
tration logic on the module senses the resulting wired-OR 
levels on the arbitration bus, and modifies the number it is 
applying to the.bus, according to the following rule: 


If, for any bit of a module’s competition number, the corre- 
sponding arbitration line shows a greater value, all lower 
order bits of the competition number are withdrawn from the 
bus. 


Once the DP388s has received the arbitration competition 
number (cn) from the Arbitration Controller, the controller 
latches these numbers into the transceiver along with the 
corresonding parity bit. A low voltage on the COMP (Com- 
petition) signal indicates that the module is competing in the 


‘arbitration. The value of each bit is compared one bit at a 


time. As shown in the Figure 4, at first, the first two bits are 
compared and, in this example, they are found equal. The 
next two bits are compared. The value of the bit 2 for mod- 


-. ule A is “1”. The value of bit 2 of module B is “0”. There- 


fore, module B will pull back its bit, and subsequently all 
lower bits; hence, it has lost the competition. Module A can 
now place its bit on the bus. This process continues until all 
bits are checked. Notice that the value of the bit 4 (Cn4) for 
module B is “1”, but this bit will not be placed as “0” on its 
output (AB4), since module A has won the bus. 


_. The Futurebus+ standard requires that all modules place 
- ‘their worst-case internal arbitration logic delay from any bus 


line ABx* to the adjacent line, AB(x—1)* or AP* into a mod- 
ule status register. This, combined with the same numbers 
from other modules, and the propagation delay of the bus, 


‘can be used to calculate a worst-case competition settling 


time. The ‘equation used is: 


where tog bus propagation delay 
* tint Module’s delay (AB<n> to AB<n—1>) 
‘text max. external module delay (if any external 
parts used). 


ABO* 
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FIGURE 3. Equivalent Parallel] Contention Logic 
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MODULE B 
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FIGURE 4. Compete Logic 


ARBITRATION COMPETITION SETTLING TIME 


Although the worst-case settling time can be calculated with 
a single equation, this gives a very long delay which is un- 
necessary for most cases. Instead, a more detailed equa- 
tion can be generated which gives a more accurate settling 
time. ~ atl” 7G 

The settling time is the period that starts when the indication 
to begin arbitration is issued. It ends when the winner’s 
competition number is valid on the arbitration bus as well as 
within the winner’s arbitration logic. This time is a function of 
the following three factors: 


1. Length of the backplane 
2. Module’s competition number 


3. The worst-case transceiver and logic delays of both the 
internal arbitration logic of the module and that of its 
competitors. , 


The interactions among the various competitor’s arbitration 
logic can be extremely complex. In most cases the winning 
arbitration number will be selected .quickly. However, the 
worst-case resolution time must be calculated in order to 
guarantee that a valid win signal is always sampled by the 
module. In the event where the system has prior knowledge 
of the set of competition numbers in use by the system at 


any one time, it may be possible to calculate a lower delay 
value. . 


For any competition number, the individual elements of the 
worst-case delay can be isolated into the following five ba- 
sic parts; Figures 5 and 6 show these delay components. 
The terminology is explained below in Table I: 


ti(x,y) is the worst-case delay from signal x to signal y of the 
internal logic of the module involved in the calculations. 
te(x,y) is the same worst-case delay for all possible external 
competitors. Within the brackets, “C’” and “W” represent 
the “compete” signal and the “win” signal respectively. The 
letter “P” represents the signal ABP* (parity). The number 
“n’” represents the signal “ABn”. To begin the competition, 
all modules are required to assert ‘‘compete” before releas- 
ing the handshake signal AR*. The minimum skew between 
the assertion of “compete” and the release of AR* can be 
subtracted from all of the delays, and it is given by (C,AR*). 
Similarly, a module signals that it has won the competition 
by asserting AQ*. The minimum delay from the recognition 
of the ‘‘win” condition to the assertion of AQ* can be sub- 
tracted from some of delays and is indicated by (W,AQ*). 
Finally tpd represents the propagation delay of signals on 
the bus from one competing module to another. 


TABLE 1. Delay Component Terminology 


Delay Component 
ti(C,4) Internal Delay from Compete Asserted to Change on ab4*. 


External Delay from Change on AB6* to Change on ab2* 
Worst-case of te(5,4) + te(4,2) and te(5,3) + (3,2) 


te(2,P) External Delay from Change on AB2* to Change on abp 


ti(C,ar*) Internal Delay from Compete Asserted to Release of ar* 


ti(4,W) Internal Delay from Change on AB4* to Change onwin 


te(5,[43]) + te([43],2) 


Internal Delay from Valid win to Assertion of aq’ 





\ 
__ti(W,aq*) 
; ‘ vA 


\ 
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COMPETE DELAY 


Assume that the two modules are competing with the num- 
bers “0” and “1” at opposite ends of the backplane as 
shown in Figure 5a. Before the first module finds out that it 
has lost the competition, its competitor must assert its com- 
petition number on the bus; this is te(C,0). Then the signal 
must propagate across the backplane, which is tpd, and the 
result must reach the internal “win” signal; this is ti(0,W). 
However, since the module will not begin timing the compe- 
tition until it has actually received the release of the signal 
AR* by its competitor. Therefore, it can subtract its competi- 
tor’s minimum competition skew, te(C,AR*), and the propa- 
gation delay of AR* across the bus; which is tod. Thus, the 
total delay for the first module is given by te(C,0) + tpd + 
ti(0,W) — te(C,AR") — tpd. This external compete logic de- 
lay minus the minimum compete-to-AR* delay of the exter- 
nal module, is known as the competition delay. It occurs 
whenever the most significant bit of the competition number 
is “0”. It adds to the worst case delay only if there are no 
other delays. (Note that it must always be less than or equal 
to zero if there is only one leading zero in the competition 
number.) 


“SLOTO 


SLOTN 
1 





ti(0,W) 
LOSE 7 
TL/F/11130-4 
te(C,0) + tpd + ti(0,W) — te(C,AR*)— tpd 
FIGURE 5a. Compete Delay 


PARITY DELAY 


Assume that two modules are competing with the numbers 
“1” and “0” at the opposite ends of the backplane. as 
shown in Figure 5b. The first module has a parity bit of “0” 
and the second module has a parity bit of “1”. The first 
module finds out that it has won the competition, immediate- 
ly; ie., te(C,0). However, parity will not be immediately cor- 
rect on the bus until its number propagates across the bus, 
this delay is tpd. Its competitor can respond by withdrawing 
its parity bit te(0,P), and the release propagates back across 
the bus, which is tpd. The parity must be valid at the first 
module before it can assert AQ". The total delay for the first 
module is given by ti(CO) + tod + te(0,P) + tpd — 
ti(W,AQ"*). An external parity logic and round-trip propaga- 
tion delay, minus the minimum win-to-AQ’* delay of the mod- 
ule, is known as the parity delay. It occurs whenever the 
least significant bit of the competition number is “1” and the 
parity bit is “‘O”. The worst-case delay cannot include both a 
defeat or compete delay and a parity delay. 


SLOTN 
0-1 


0-0 
WIN 
0-1 


ti(C,0) 
tpd 
1-1 


LOSE 
1-0 


te(0,P) 
tpd 
1-0 
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ti(C,0) + tod + te(0,P) + tod — ti(W,AQ*) 
FIGURE 5b. Parity Delay 


ITERATE DELAY 


Let us assume that two modules are competing with the 
numbers “10” and “01” at opposite ends of the backplane 
(Figure 5c). \n this case, the first module asserts its competi- 
tion number on the bus, ti(C,0). The most significant bit must 
propagate through across the bus, tpd. Its competitor. must 
release its least significant bit, te(1,0). The release must 
then propagate back across the bus, tpd and the module 
must recognize that it has won, ti(0,W). The total delay for 
the first module is given by ti(C,1) + tpd + te(1,0) + tpd + 
ti(0,W). An internal logic delay is known as an iterate delay. 
Iterate delay occurs wherever the pattern “10” appears in a 
module’s competition number. ; 


SLOTO —« SLOTN 
10 «Ot 
. “foo tc,1) 
WIN 

01 tpd 


11 te(1,0) 
LOSE 
10 - tpd 





10 4(0,W) 


TL/F/11130-6 
ti(C,1) + tpd + te(4, 0) + tpd + ti(0,W) 
FIGURE 5c. Iterate Delay 


DEFEAT DELAY 


As shown in Figure 6a, assume that three modules are com- 
peting with the numbers “100”, “010” and “101”, with the 
first one located at the opposite end of the backplane from 
the other two. Here, the first module asserts the most signif- 
icant bit of its competition number on the bus. This causes 
the second competitor to release its middle bit. This in turn 


~ allows the third competitor to assert its least significant bit, 
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which causes the first module to lose the competition. Fig- 
ure 6a shows the total delay for the first module given by 
ti(C,2) + tpd + te(1,0) + tpd + ti(0,W). An extra defeat- 
causing external logic delay is known as a defeat delay. This 
delay occurs wherever the pattern 100” appears in mod- 
ule’s competition number. It adds to the worst-case only if it 
is part of the last iterate delay of the competition number. 








SLOTM SLOTN 
010 101 


SLOTO 
100 


000 ti(C,2) 


te(2,1) 


101 ti(0,W) 
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ti(C,2) + tpd + te(2,1) + te(1,0) + tpd + ti(0,W) 
FIGURE 6a. Defeat Delay 


GLITCH DELAY 


Let us now assume that three modules are competing with 
the numbers ‘'110”, “010” and “101”, with the first one at 
the opposite end of the backplane from the other two (see 
Figure 6b). The first module asserts the most significant 
two bits of its competition number on the bus. This causes 
the second competitor to release its middle bit. Now in a 
transmission line environment, the current that was flowing 
through this bit crosses the receiver threshold of other mod- 
ules. This glitch will propagate to the first module, where the 
driver will adjust the amount of sink current to bring back the 
signal to its correct voltage level. In the mean time, for the 
third module, it appears as if it has won the competition. 
This module will not release its least significant bit until the 
correct voltage has propagated across the bus. The third 
module will then allow the first module to win the competi- 
tion. The total delay for the first module is given by ti(C,2) + 
tpd + te(2,1) + 2tpd + te(1,0) + tpd + ti(0,W). An extra 
wireOR-caused external logic and round-trip propagation 


SLOTM SLOTN 
010 101 


SLOTO 
110 


000 ti(C,2) 


tpd 


111 te(2,1) 
LOSE 
110 tpd 


100 
WIN tpd 
101 


111 te(1,0) 
LOSE 
110 


110 ti(0,W) 
TL/F/11130-8 
ti(C,2) + tpd + te(2,1) + 2tpd + te(1,0) + tpd — ti(0,.W) 
FIGURE 6b. Glitch Delay 
The minimum and maximum propagation delays from the 


' ABO to “WIN” signal asserted are 6 ns and 28 ns respec- 


delay is known as a glitch delay. It occurs wherever the. 


pattern 110” appears in a module’s competition number. 


It is important to note that the above listed delays can be 
added to each other. However, the compete delay cannot 
combine with any other delay. The parity delay cannot coin- 
cide with a defeat delay. The defeat delay will add to the 
worst-case settling time only if it is part of the last iterate 
delay of the competition number. 


For example, a competition number with the shortest set- 
tling time is 11111111-1". From the assertion of “com- 
plete” to the detection of ‘win’, the total time is ti(C,W), or 
the maximum propagation delay of the parallel contention 
logic. The minimum internal skew, ti(C,AR*), can then be 
subtracted from this. A competition number with the longest 


settling time is “‘11010110-0”. This number has three iterate 


and two glitch delays. The worst-case settling time is: 
ti(C,7) — ti(C,AR*) + te(7,6) + te(6,5) + ti(5,4) + te(4,3) 
+ ti(3,2) + te(2,1) + te(1,0) + ti(0,W) + 10tpd. 


2-47 


tively for the “win” or “greater than” conditions. The mini- 
mum and maximum propagation delays from the ABP to 
PER are 6 ns and 28 ns respectively. 


Figures 7 through 9 show output waveforms of the DS3885 
under various test conditions. The DS3885 device was 
mounted on a wire-wrapped board which was placed in the 
slot 1 of the Futurebus+ backplane. The supply voltage 
was 5V. As shown in Figure 7, the propagation delay from 
the time COMPETE goes low (active) to AB7 is 6.135 ns. 
The rise and fall times of the output signal AB7 are 4.775 ns 
and 1.384 ns respectively. Figure 8 shows the WIN condi- 
tion which is simulated by connecting the six competition 
bits inputs Cn<7,1> to ground and providing a pulse to the 
competition bit input Cn<O>. The load on the output com- 
prised of a 33 pF capacitor in parallel with 1 kf resistor. 
However, the total load capacitance including the probe, 


. wiring etc., is approximately 50 pF. The propagation delay 


from ABO to WIN, in this case is 14.65 ns. As can be seen, 
even with faster rise and fall times, the DS3885 generates 
noise-free output signal with BTL voltage levels. Figure 9 
shows propagation delay from AB7 to ABP (parity) which is 
36.91 ns. 


SUMMARY 


Like all other transceivers in the Futurebus+ chipset, the 
DS3885 also contains glitch-free power up-down feature, 
on-chip bandgap reference for the receiver and has con- 


_ trolled rise and fall times. It contributes as a valuable device 


for resolving the arbitration competition process on the Fu- 
turebus+. Although it has been designed to support the 
Futurebus + arbitration process, it can also be used to sup- 
port the messaging function in the central arbitration 
scheme. 
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FIGURE 9 
Figures 10 through 79 show test circuits and timing diagrams used to measure various parameters of this device. 
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FIGURE 10. Driver Propagation Delay Set-up 
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FIGURE 12. Driver: COMP* to AB7 
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FIGURE 13. Receiver Propagation Delay Set-Up 
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FIGURE 14. Receiver: ABn to CNn 
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FIGURE 15. Receiver Enable/Disable Set-Up 
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FIGURE 17. ABO to AA* 
1.5V 


TL/F/11130-19 
FIGURE 16. Receiver: RE* to CNn 
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TL/F/11130-21 
FIGURE 18. ABO to WIN*, ABP to PER* 
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FIGURE 19. ABn to AB<n—1>, AB7 to ABP 
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ABSTRACT 


Futurebus+ is a specification for a scalable (32/64/ 128 or 
256-bit wide) bus architecture. Arbitration is provided by a 
fully distributed, one or two pass, parallel contention arbiter 
with allocation rules to suit the needs of both real-time (pri- 
ority based), and fairness (equal! opportunity access based) 
configurations. Two transmission methods are provided: (1) 
a technology-independent, compelled protocol, supporting 
broadcast, broadcall and transfer intervention (the minimum 
requirement for all Futurebus + Systems), and (2) a configu- 
rable transfer-rate source-synchronized protocol supporting 
only block transfers and broadcast for the maximum per- 
formance systems. Futurebus+ takes its name from its goal 
of being capable of the highest possible transfer rate con- 
sistent with the technology available at the time modules 
are designed, while ensuring compatibility with all other 
modules designed to this standard before and after. The 
plus sign (+) refers to the extensible nature of the specifi- 
cation, and the hooks provided to allow further evolution to 
meet unanticipated needs of specific application architec- 
tures. This paper describes the history, structure and appli- 
cations of the Futurebus+ architecture. 


HISTORICAL PERSPECTIVE 


Futurebus+ is a revised and substantially extended version 
of the original. IEEE 896.1—1987 Futurebus standard, 
where the basic protocols and facilities of the new Future- 
bus+ were developed.. 


From 1983 to 1987. the IEEE P896 Futurebus Working 
Group, provided a forum for leading experts to develop 
innovative. technology: and protocols for a scalable per- 
formance multiprocessor system bus. The most recent 
Futurebus+ efforts, from 1988 onwards, represented a 
commercial consolidation of all the basic Futurebus philoso- 
phies into a realizable and practical standard as an industry 
consensus developed between the major organizations who 
became interested in developing products based on 
Futurebus +. 


During early 1988, the VME International Trade Association 
(VITA) saw the need to develop a strategy which would lead 
to the definition of a Next Generation Architecture Bus Stan- 
dard, to follow the widely successful IEEE 1014: VMEBus 
standard. They developed a set of requirements which in- 
cluded openness, performance goals, and system facilities 
and flexibility which would not hinder systems using this bus 
for many. generations of computer systems. In December 
1988, VITA formally announced its intention to base its 
“VME Futurebus+ Extended Architecture” (VFEA), on a re- 
vised and extended IEEE 896.1—1987 Standard, in con- 
junction with the IEEE Futurebus-+ Working Group. 


Around the same time, the US Navy’s Next Generation 
Computer Resources Program (NGCR) chartered a Back- 
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plane Working Group to develop a set of requirements for 
use in future Mission Critical Computers. A principal require- 
ment was that the chosen standard be likely to become a 
major commercial success also, in order that the US Navy 
could capitalize upon the systems expertise developed from 
R & D Funding provided by the commercial and industrial 
sectors. All known existing and proposed bus architectures 
were evaluated against a set of criteria. 

Futurebus scored substantially higher than the other con- 
tenders in almost all categories. After significant internal dis- 
cussion at the highest levels of the DOD, the Pentagon an- 


nounced in December 1988, their selection of the IEEE 


896.1—1987 Futurebus as the basis for all future US pais 
mission critical computers. 


A third major influence on the specification came from the 
IEEE P1496 Rugged Bus Working Group, who had, in 1986, 
decided to develop a ruggedized specification for a back- 
plane bus. Rather than develop an entirely new bus from 
scratch, the Rugged Bus Working Group chose to use the 
IEEE P896.1—1987 Standard as a base from which to de- 
velop their application needs. In November 1988, at a Joint 
Rugged Bus/Futurebus Working Group meeting, the two 
groups agreed to merge their efforts for a single bus stan- 
dard, to be called Futurebus+. The Rugged Bus Working 
Group brought significant additional skills to the joint activi- 
ty: real-time, fault-tolerance, maintainability and environ- 
mental conditions, in addition to the dedication and hard 
work of their members who became an integrated part of 
the team which defined and reviewed the latest Futurebus + 
specification. 


An additional strong influence on the spseilieailon came 
from the Multibus Manufacturer’s group who, :in February 
1989, announced their intention to pair IEEE 1296 (Multibus 
ll) with the developing Futurebus+ Specifications, into a 
common “Futurebus+ Extended Architecture” (FBX). From 
that point onwards, member companies of the Multibus 
Manufacturers Group provided technical support for the 
Working Group activities, and contributed greatly to the co- 
operative spirit among what were previously competing fac- 
tions in the bus industry, to develop a single cache coherent 
bus architecture for the industry, which would now compete 
as a truly open standard against the myriad of proprietary 
and semi-proprietary architectures which had plagued the 
industry in previous generations of computers. 


MAJOR FEATURES 


Futurebus +. represents a major paradigm shift for the bus 
industry. It is the first comprehensive bus architecture de- 


signed a-prior/ to be an OPEN standard (An interface speci- 


fication for which there are no restrictions for who may use 
i, and which was explicitly designed to support multiple 
generations of computer technology. 
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What is Futurebus + ? 


Futurebus+ will benefit end users immeasurably, by allow- 
ing vendors to build systems which not only have a much 
greater degree of compatibility, but which are ‘gracefully 
upgradable”, preserving investments already made in the 
boards, enclosures, power systems, peripherals and other 
hardware (and software) as new improvements in processor 
architecture, levels of integration, and clock speed, are im- 
plemented. 

Futurebus+ derives its name from its lack of built-in obso- 
lescence parameters, and its upwardly compatible architec- 
ture and protocol extensions. Futurebus+ represents a sig- 
nificant departure from the philosophy of other standard or 
proprietary buses. The most important objectives of the Fu- 
turebus+ project were: (1) to create a bus standard that 


would provide a significant step forward in the facilities and 
‘performance available to the designers of future multipro- 


cessor systems, and (2) to provide a stable platform upon 
which manufacturers can base several generations of com- 
puter systems. 


In order to meet this objective, the following requirements 
were set: 


e Architecture, processor and jechnioay independent (at- 
tributes of a truely OPEN Standard). 


A basic asynchronous (compelled) transfer protocol for 
- simple, higher reliability operation with a handshake flow 
control over each word of data transferred. 


An optional source-synchronized (packet) protocol for 
the highest possible performance, with flow contro! over 
each block of data transferred. 


e No technology-based upper limit to the performance of 
the bus in both modes {i.e., limited only by the laws of 
physics—not by the technology). 


. Fully distributed parallel and arbitration protocols to pro- 
vide the minimum possible number of single point failure 
mechanisms. 


Parity protection on all lines, and feedback checking 
where possible (e.g., modules may write to themselves to 
facilitate self-testing). 


Multi-level mechanisms for locking of modules, and the 
avoidance of deadlock or livelock. 


Circuit switched and split transaction protocols. Plus sup- 
port for memory controller commands to implement re- 
mote lock and other SIMD-like operations. 


Support of real-time mission critical computations. (Multi- 
ple priority levels with which to arbitrate, and the consist- 
ent treatment of priorities throughout the arbitration, 
message and DMA protocols. Plus support for the distrib- 
uted clock synchronization protocol defined in IEEE 
P896.3.) 


Support for fault-tolerant and high availability systems 
(Dual bus operation, fault detection and isolation mecha- 
nisms and live insertion and withdrawal of modules). 


Direct support for snoopy-cache based shared-memory 
systems, with recursive protocols to support single or un- 
limited size systems consisting of arbitrarily connected 
buses. 


Recognition and support of strong and weak sequential 
consistency (time order assumptions). 
Compatible message transport definition supporting a 
number of message passing protocols. 


TECHNOLOGY INDEPENDENCE 


A unique attribute of the design of the Futurebus+ proto- 
cols is their technology independence: achieved through 
basing the protocols on fundamental protocol! and physics 
principles and optimizing them for maximum communication 
efficiency (and hence throughput) rather than for a particular 
generation or type of processor. Timing and handshake pro- 
tocols are thereby governed by ‘“‘law of nature” types of 
constraints rather than limitations of current and projected 
technology such as device propagation delays, and capture 
windows. 


The benefits of technology independence are reflected in 
the principle of no technology-based upper limit to the per- 
formance of the bus. The configuration or transaction capa- 
bility modes guarantee interoperability when two boards of a 
different speed, or different generation, communicate on the 
same bus segment; thus providing the Futurebus+ with an 
unprecidented ability to support multiple generations of 
computers, well into the 21st century. 


This principle of design longevity also provides a self-adapt- 
ing performance span which allows graceful upgrades in 
computer equipment. This leads to less customer annoy- 
ance, greater confidence in their supplier and the equipment 
they sell. Manufacturers are also likely to find significant 
advantages in their manufacturing capability, the learning 
curve of their design engineers, and a strong sie ad- 
vantage in credibility to their customers. . 


Fundamental to the compatibility of slow, fast, old or new 
modules attached to the same Futurebus+ segment, is the 
notion of broadcast. Each connection phase (address cycle) 
is broadcast in a way which guarantees that each module 
on the same bus segment is able to decide whether or not 
to participate in the forthcoming data transfer phase. This 
turns out to be a basic requirement of a snooping cache 
coherence scheme, which allows multiple caches to search 
their directories to see whether or not they ought to be inter- 
ested in the transaction. Even then, the protocols provide 
for the performance enhancements possible when a master 
knows that other modules will not be interested, by indicat- 
ing whether other caches should even bother to search their 
directories or not (for example, when a cache block is re- 
placed and ownership is transferred back to the main mem- 
ory, or when the transactions are using the message pass- 
ing mode). 


The P896.1 specification may be implemented using any 
logic family (e.g., TTL, BTL, CMOS, ECL, GaAs) providing 
the physical implementation is constrained’ such that it 
meets the Futurebus+ signaling requirements (incident 
wave switching, and relative skews between information 
and synchronization lines). 


Futurebus+ protocols may be used at any level in the sys- 
tem hierarchy. Device to device, board to board, or system 
to system. These protocols are particularly powerful when 
used at two or more levels in a hierarchical bus system.: 


ARCHITECTURE INDEPENDENCE 


Futurebus + is architecture independent, providing a flexible 
and elegant general purpose solution to cache consistency, 
within which other cache protocols will operate compatibly, 
while at the same time providing an elegant unification: with 
a message passing transport protocol. 








There are many exceptionally powerful features implicit 
‘within the Futurebus+ specifications which may not be ob- 
vious on a first reading of the specification. The Working 
-Group chose to provide a flexible set of tools within which 
an implementation can be crafted to suit a wide spectrum of 
applications. Many of the protocol features may be used not 
only, for the immediately obvious purpose, but are capable 
of being utilized for other purposes, many of which were 
recognized by the Working Group, but which were omitted 
from the descriptions in order not to over-complicate them. 


Implicit in the philosophy of the Futurebus+ specification, is 
the concept that large systems may be built from smaller 
‘subsystems, and those small subsystems may in turn be 
built from yet smaller subsystems. Examples of which in- 
clude the choice of split or interlocked transactions and a 
fully recursive, truly hierarchical cacheing paradigm. This is 
in anticipation of future generations of systems, which will 
inevitably utilize many levels of caches and internal/external 
buses. The Futurebus+ protocols will work well at any or 
all \evels in this hierarchy; since for each generation of com- 
puter systems, each bus is absorbed into the packaging 
technology one level-lower than the previous generation: 
traffic flowing on backplane buses today will flow on the on- 
board buses of tomorrow; and on chip-level buses soon af- 
ter that! . . 
Futurebus+ has been designed with large scale integration 
of the bus interface in mind. A severe restriction on the 
number of signals has allowed the bus to steer clear of 
being intrinsically expensive. Hence, while initial implemen- 
tations of the Futurebus+, may require multiple interface 
devices, the learning curve, and volume, will allow these to 
be further integrated and for the market forces to rapidly 
bring down the cost of the interface to become consistent 
with even the lowest cost workstations, industrial and per- 
sonal computers. 


PARALLEL PROTOCOL 


The principal objective behind the design of the parallel pro- 
tocol, was to achieve the highest possible transfer rate con- 
sistent with the implementation technology and manufactur- 
ing constraints at the time the modules were designed, al- 
lowing both backwards and forwards compatibility. This 
“technology-independence” aspect of the Futurebus+ pro- 
tocols provides the following advantages: 


¢ A long design longevity for the bus, consistent with the 
attributes of a widely implemented standard for commer- 
cial, industrial and military requirements. Futurebus+ 
has been designed in anticipation of its continued use 
well into the 21st century. 


Graceful upgrade of system components, rather than the 
more usual “throw it all away and start again” scenario 
that occurs with traditional computers when higher clock- 
rate processors become available. 


Flexible tradeoff between cost and performance at any 
one point in time. Boards may be designed with exotic 
technologies to achieve the highest possible perform- 
ance, or with more cost-effective technologies to achieve 
excellent cost/performance tradeoffs, and both can op- 
erate within the same system (providing they conform to 
the same profile). 


The Futurebus+ parallel protocols support both connected 
and split transactions. Simplistically speaking, connected 
transactions are cheaper, easier to implement, but are 
slowed by the access time of the memory. Split transactions 
are more complex, expensive, but provide higher multi- 
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stream system bandwidth since the bus need not be idle 
during the memory access time. Connected transfers pro- 
vide lower latency for access to memory (hence single- 


‘stream performance is optimized), split transactions provide 


more concurrency in the protocols, hence they optimize 
multi-stream performance. Both are needed in.a system ar- 
chitecture. Connected transfers provide a cost-effective 
performance for !/O operations, while split transactions pro- 
vide the maximum performance required by MPU/Cache- 
memory operation. 


Current RISC or CISC Microprocessors do not easily sup- 
port a command structure for memory controllers to perform 
remote lock operations. Futurebus+ provides a simple 
workaround for this: use the split transactions for everything 
with the exception of lockvariables, and automatically revert 
to using connected transactions to perform RMW type oper- 
ations. This allows the performance enhancements of split 
transactions to be obtained without having to redesign the 
processor, or utilize ugly software workarounds which re- 
quire existing code to be modified and adversely affect the 
performance of the system. 


SYNCHRONIZATION DOMAINS 


The most frequently misunderstood aspect of bus design 
and the one which invokes the most religious fervor among 
protagonists, is the synchronization protocol. 


One of the basic arguments for the asynchronous (source 
synchronized) protocols in Futurebus+ is that it allows the 


‘synchronization domain of the sender to extend along the 


bus segment, presenting only one synchronization interface 
between the bus and the receiver. This contrasts with cen- 
trally synchronized buses which require three separate syn- 
chronization domains (sender, bus, receiver). Synchroniza- 


tion interfaces mean performance is lost due to resynchroni-, 


zation delays and MTBF is reduced due to metastability. 
Since Futurebus+ has only one synchronization interface, it 
will naturally yield a higher performance than any centrally 
synchronized bus. 


SCALABILITY AND PERFORMANCE. 


Scalability of cost and performance were early requirements 

in the design of the Futurebus+ protocols. Although Future- 

bus + is basically a 64-bit address architecture, employing a 

standard 64-bit multiplexed address/data highway, a 32-bit 

Address/Data subset , and 128-bit or 256-bit data superset 

is also provided. Perhaps more importantly, the perform- 

ance scales over time with a fixed width highway, allowing 

for example, systems to be built with 20 ns transfers in 1991 

and 10 ns transfers by 1995. 

Note: While 10 ns per transfer is often regarded as an upper limit due to the 
physics of the bussed transmission line environment, this is a conser- 
vative estimate based on measurements with a full-length “back- 
plane” implementation of Futurebus+ protocols and an electrical en- 
vironment, supporting upwards of 20 boards. Systems with fewer 
modules, shorter stubs, and shorter backplanes or no backplanes at 
all (i.e., on-board implementations of the Futurebus+ protocols), will 
be able to significantly exceed this limit. 

Multiplying these numbers by the data highway width op- 
tions (32, 64, 128, and 256 bits), provides a protocol 
throughput (with an appropriate electrical environment), of 
approximately 100 Mbytes/second at the low-end for sys- 
tems using the 32-bit subset in 1990, while systems using 
the 256-bit superset in 1995 will peak at 3.2 GBytes/sec- 
ond—a dramatic demonstration of the benefits of a scalable 
design. 


é + SNqosNyny S! JEU 


What is Futurebus + ? 


There are two principal reasons why Futurebus +: is able to 
attain this level of performance, while other buses cannot: 
(1) All Futurebus+ protocols are source synchronized, 
meaning that the synchronization signal is always emitted 
by the same module which emits the information signals, 
thereby eliminating spatial skews, and (2) substantial effort 
has been put into the understanding the signaling environ- 
ment to guarantee that receivers are triggered by the inc/- 
dent wave from the driver.as it passes by along the bus 
lines. : 
Note: Spatial Skews result when there is a space (and hence tine) differ- 
ence between the transmitting and receiving modules, and the pas- 
sage of data between them is synchronized by a signa! transmitted by 
a 3rd party. For example, a bus with a central clock source must 
account for an additional uncertainty in the arrival of data at a receiver 
equal to the space (time) difference between the sender and receiver 
of the data, independently of the mechanism used to distribute the 
central clock. 
Another dimension of scalability for the Futurebus, which 
lends itself also to fault-tolerant applications, is the use of 
dual or multiple parallel Futurebus’s. The locking mecha- 
nisms, cache coherence mechanisms, and the general ar- 
chitectural facilities are designed such that they can be 
readily applied to such applications. Moreover, it may well 
be possible that implementations of dual 64-bit or 128-bit 


buses (as opposed to’ single 128-bit or 256-bit buses) are 


likely to lead to better multi-stream system throughput (with 
a fixed number of bytes per block), due to the smaller frac- 
tion of the overall transaction time used as overhead in the 
narrower width implementations of the bus. 


ANOTE ON PERFORMANCE 
Since Futurebus + isa technology-independent specifica- 


tion, there is very little in the protocol specification which 


would indicate what their actual performance would be in a 
specific implementation, without building and eitpeitig such a 
system. 


Although there is, in principle, no upper limit to tha netfcii 
ance of the Futurebus, there are some basic issues regard- 
ing the achievable performance which are not widely under- 
stood. The actual performance of any bus in any particular 
system will be a function of me following three critical ele- 
ments: 


¢ The theoretical cleanliness of the protocols. e.g., do the 
‘protocols carry any unnecessary overhead; do they carry 
~ any unnecessary constraints of synchronism to a central 
~ «clock, or too many round-trip delays in the handshakes; 
do they incorporate fixed technology constraints au as 


arbitrary set-up and hold times? 


‘The architecture of the system in which the bus is ised 
The most theoretically perfect bus protocol will grind to a 
snail's pace in a poorly architected system. Very often, it 
is the memory system bandwidth which is being mea- 
sured rather than the intrinsic protocol bandwidth of the 
bus. Systems which perform random transfers can never 
sustain as high a transfer rate over the main highway as 
systems specifically designed to take advantage of the 
intrinsic efficiencies of the memories and bus protocols, 
such as block transfers. 


The implementation. Only if full advantage is taken of 
available semiconductor technologies, will the protocols 
perform at their full potential. Since the Futurebus+ is a 
truly open standard, its benefits are available to any and 
all who choose to adopt the bus. Competitiveness, and 
added-value, will now focus on the quality and thorough- 
ness of the implementations. Since Futurebus+ proto- 
cols provide significant room for learning-curve effects in 
the industry, one can expect a rapid evolution in the per- 
-- formance of systems which use Futurebus+, through a 
steady but definite improvement in the implementation. 
Data from various simulation results and reports on 
anticipated semiconductor performance have been used to 
predict the expected peak performance figures for the 
Futurebus+ over time as shown in Figure 7. The packet 


protocols are shown from a 1991 baseline because of the 


anticipated wide availability of devices which can implement 
this mode during that time-frame. Conservative assumptions 
were used in the development of this model; it is quite possi- 
ble for some commercial organizations to be well ahead of 
these performance curves when they introduce their. prod- 
ucts. | y 
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ARBITRATION 


Futurebus+ uses a highly evolved version of the Parallel 
Contention Arbiter. This mechanism arbitrates among active 
contenders through a combinatorial logic network distribut- 
ed among all possible contenders using a set of simple 
bussed lines connecting them. By applying a unique arbitra- 
tion vector to this logic, one contender only (with the highest 
arbitration vector) will be uniquely selected as the winner. 
The Futurebus+ implementation additionally distributes the 


responsibility for synchronization of this mechanism among’ 


all the contenders, such that no central logic whatsoever is 
required on the bus segment. 


Although not as familiar as a central request/grant scheme, 


the parallel contention arbiter used in Futurebus + has a 
number of Significant advantages: 
e The current master can observe any requests (and their 


priority). This allows. the current master to make a rea- 
sonable decision as to whether it should give:up the bus 


immediately (high priority request), at the next ‘‘conve- . 


nient” breakpoint (low priority request), or to continue 
until the end of a potentially long block transfer or series 
of transactions (no requests pending). . 


Multiple priority levels. Allows real-time systems to deter-: 


ministically allocate bus bandwidth to those processors 
running the most critical tasks in situations of high sys- 
tem load, i.e., it allows one to determine if a process is 
schedulable (guaranteed to meet its deadlines even un- 


der conditions of high system load), and improves the’ 


probability that a process is schedulable within a system 
with fixed available bandwidth. 

A master-elect can be pre-empted by:a higher priority 
contender which arrives after the arbitration has taken 
place, but before the current master has relinquished the 
bus. This allows the higher priority contender a signifi- 
cantly shorter average latency to access the bus. 


Arbitration Messages (or events) can be broadcast on 
the arbitration bus without the need to disturb the traffic 
currently underway on the parallel bus. This mechanism 
can be used to implement, for example, interrupts, tar- 
geted events and parallel processing rendezvous at syn- 
chronization points before proceeding; all without the 
need for dedicated lines on the bus for those miscellane- 
ous system control functions. 


Implemented in a purely text-book fashion, and with all the 
parameters of the arbitration network set to their maxi- 
mums, this arbitration mechanism will perform approximate- 
ly similar to a daisy chained mechanism, but without the 
inherent disadvantages of such a scheme. Significantly fast- 
er implementations may be designed, which still fully con- 
form, by noting that the arbitration parameters (arbitration 
vector, arbitration contest settling time, Wired-OR Glitch fil- 
ters, etc.) can be traded off against the number of active 
masters in the system, the total number of modules at- 
tached to any one bus segment, and the length of that bus 
segment: all parameters which can be ascertained during 
the system initialization phase. Also, in order to take advan- 
tage of the performance of higher speed modules (i.e., mod- 
ules with faster logic), two arbitration “speeds” are dynami- 
cally selectable. This ensures that the compatibility is main- 
tained among old and new boards attached to any bus seg- 
ment. 


A unique aspect about the Futurebus+ arbitration scheme, 
is the optional “‘idle-bus” arbitration method, used when 
there is only one requesting master. This method, using the 
Address/ Data lines to signal a request when the bus is idle, 


~ provides the fastest possible latency for a module to access 


a memory subsystem. In the event that two or more masters 
are detected during this request phase, the scheme auto- 
matically reverts to using the parallel contention arbiter 
method, already started concurrently with the fast idle bus 
method. The result is a significantly faster average latency 
for a module to access the memory subsystem. Used in 
combination with the connected bus protocols. This can re- 
sult in a significant reduction in the miss penalty of modern 
RISC processors, as compared to all other bus designs. 


’ SYSTEM ARCHITECTURE SUPPORT 


The Futurebus+ specification has been written to provid 


. support for a wide variety of system architectures. Within a 


single bus segment, both functionally distributed (message 


‘ passing) and shared memory (cache coherent) systems 
“may.coexist. For multi-crate systems, Futurebus+ has a 


number of companion standards offering a bridging service 
to other bus standards. This wide range of options will allow 


.. a smooth transition from existing buses to Futurebus+ and 
~ beyond to other advanced. interconnection architectures 


such as the Scalable Coherent Interface (SCI): a ring-based 


~ interconnection for-large scale parallel processing system 
‘implementations. It also allows the needs of secure data 


and tightly-coupled parallel processing regimes s to be bal- 
anced. 


A_message passing architecture is, in its purest form, a 
write-only system. In such a system, a module requiring ac- 
cess to data sends a request message to the module own- 
ing the data; the responding module will reply at some time 
later by writing the data to the requestor. It is easy to see 
that access restrictions may be readily implemented in such 
a system without cutting down on the available bus band- 
width; the responder simply checks the authorization of the 
requestor before replying. What is not immediately obvious 
is that such a system can make very efficient use of the bus. 
First, only write transactions are being used, and write trans- _. 
actions are inherently more efficient: requiring only the pre- 
sentation of the data and a response, rather than a request, 
an access time for the data and a response, as is required 
for read transactions. Second, messages use fixed size 
blocks, allowing burst transactions to amortize the cost of 
transaction setup over the block. Message passing systems 
also have the advantage of being simple to design and ana- 
lyze since nothing is shared and all transactions are inher- 
ently split. 

Futurebus+ describes an optional message passing archi- 
tecture in Chapter 9. The P896.1 model uses a default mes- 
sage frame of 64 bytes (note the compatibility with the buff- 
er sizes needed by the cache coherence protocols), a 
broadcast mailbox with a message filter and point to point 
request and response mailboxes. Messages are transmitted 
without the use of any special bus level protocols. Only two 
of the Futurebus+ transaction types are used: Write-un- 


locked } and write-no- -acknowledge. This makes Futurebus + 


Tiessage passing “easy to ‘implement and easy to add to an 
existing interface design. 








Shared memory architectures represent a different ap- 
proach to system data flow. In this model, all data needed 
for use by more than one resource within the system is held 
in a global, shared memory subsystem, accessible to all bus 
masters within the system. This method of sharing data 
would be costly in terms of bus bandwidth and access laten- 
cy if all modules had to compete for access to the same 
physical memory module(s), so caching and split transac- 
tions are provided to enable much higher performances to 
be obtained by eliminating unnecessary contention. A 
shared memory model is extremely useful when multiple 
processors are operating on the same data and is the pre- 
ferred architecture for use in tightly-coupled_multiprocess- 
ing. The use of constructs suchas caches and split transac- 
tions requires that the hardware implement a well-thought 
out series of protocols to ensure that all processors always 
operate on valid data only. 


The shared memory and message passing models are not 


mutually exclusive within the Futurebus+ environment: they . 


can readily co-exist, allowing the system integrator to meet 
seemingly orthogonal requirements. ° 


CACHE COHERENCY 


One specific application which the Futurebus+ is extraordi- 
nary well suited to, is the shared memory multiprocessor. 
The Futurebus+ protocols include all the transaction types 
necessary to drive the states of various cache modules to 
conform with almost any arbitrary cache coherence proto- 
col. This turns out to be easier than it sounds. The Future- 
bus Working Group discovered, early in 1986, that. all the 
existing cache coherence schemes are really variations on 
the same theme, but with an arbitrary nomenclature for the 
cache states. The result was the development of a unified 
cache model called the MOESI model. Futurebus+, uses a 


slight restriction of this model (MESI), in which tradeoffs 
were made to increase system performance and to allow 
operation of the protocols across bridges. It is recognized 
that different schemes may be needed to yield the best 
price/performance tradeoff for different applications, but 
that all the chosen schemes within any one system are re- 
quired to interoperate. 


More interestingly, perhaps, is the notion that the Future- 
bus+ cache consistency scheme works in an environment 
with multiple logical Futurebus’s connected in a hierarchical 
fashion. Although the parallel protocols are notionally com- 
prised of complete “connected” transactions, they may be 
recursively “split”, by bus repeaters which insist that a copy 
of the transaction must be repeated on adjacent buses to 
which are known to have copies of the same cache block. 
Inherent in this assumption is that each bus repeater con- 
tains a cache (at least the cache tag), which can record the 
passage of a cache block to the neighbor bus, and thereby 
maintain the knowledge that they must pass on future refer- 
ences within that block to the other bus. 


Perhaps most interestingly, and this is one of the many hid- 
den benefits of the Futurebus+ architecture, these proto- 
cols are exactly the same whether they are being recursive- 
ly applied to a system with multiple Futurebus+ backplane 
segments in different crates, or to a system within one crate 
(a single backplane), and multiple local Futurebus+ seg- 
ments on each of the boards, each with multiple processors 
on them. 


Futurebus+ based multiprocessor systems scale well with 
the number of processors because clusters of processors 
can be interconnected on different buses, with each bus 
connected to another by a cacheing bus repeater. Thus, 
traffic on one bus will disturb a remote bus only if the bus 
repeater cache misses on a block which exists on the re- 
mote bus. Just as a cache acts as a filter to keep traffic 
generated by a processor from reaching the first level bus, 
the cacheing bus repeater also acts as a filter to keep traffic 
generated on the first level bus from reaching the second 
level bus. Even moderately well architected Futurebus + 


- based systems will scale up to many 10’s of buses, and 


several hundred processors without showing signs of band- 
width saturation. |. 
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SEQUENTIAL CONSISTENCY 


Computer Architecture has been evolving for many years, 
and many problems which now seem familiar, were far from 
obvious when they were initially recognized. Several years 
ago, the Working Group solved some fundamental physical 
and conceptual problems concerning the physics of the 
backplane environment, and the design of the bus protocols 
to provide general mechanisms to support cache coheren- 
cy. Recognizing that there are likely to be many more prob- 
lems which have not yet been either widely recognized, or 
well articulated, the Futurebus+ Working Group has incor- 
porated many (mostly hidden) hooks into the specifications 
to allow its evolution, in a compatible way, to meet both 
anticipated and unforeseen future requirements. 


For example, the Futurebus+ protocols have been carefully 
designed to be fully consistent with the physical model of 
the universe implied by special relativity. The model dispels 
the myth of the concept of simultaneity, because all laws of 
physics, including electrodynamics, optics, mechanics, and 
data location and movement are invariant with respect to all 
coordinate systems, and that spatial distribution is equiva- 
lent to time (in this case, latency). It is the lack of recognition 
of this principle in computer science which gave rise to the 
conceptual difficulties called sequential consistency. 


Sequential consistency was first recognized in early 1988 by 
the Futurebus+ Working Group when trying to reconcile the 
view of the universe from the different perspectives of the 
programmer and hardware engineer. It is the assumption, 
often made without explict reference by programmers, that 
the order of events observed by any one device is the same 
as any other device. Unfortunately, when the transmission 
time of an event or protocol packet (due to the finite speed 
of light) is significant relative to the period between events 


occurring in the system, this assumption is no longer valid, 
since it violates the principle of relatively (that there is no 
absolute frame of reference, and the order of events de- 
pends on both the space and time coordinates of the ob- 
server relative to the rest of the system). 


Futurebus+ provides support for dynamically choosing be- 
tween strong and weak sequential consistency. One way 
this is supported is through the split transaction protocol, by 
either posting the writes and continuing without waiting for a 
response (weak consistency), or by requiring the processor/ 
cache to wait for all responses from other blocks before 
continuing (strong consistency). 


The effect of strong sequential consistency is to sequential- 
ize several variable updates through one place in space- 
time (the current owner). Since in the MOESI model there is 
by definition only one current owner (although there may be 
several surrogate owners in the bridges), the effect is to 
create a single point in space through which the synchroni- 
zation can take place. 


it was important to provide support for strong consistency 
since many experts believe that sequential ordering of 
events must be guaranteed in order to ensure the correct 
operation of certain programs (this is currently an outstand- 
ing research question in the academic world). However, 
strong sequential consistency significantly reduces the 
amount of concurrency allowed in the system, and can 
therefore have a highly detrimental effect on multiprocessor 
system performance. Weak sequential consistency is pro- 
vided for those new programs wishing to take maximum ad- 
vantage of the concurrency available in a system, but which 
are cognizant of the programming constraints needed to en- 


sure correct operation when strong sequential consistency 
is not guaranteed. i ee 
Mechanisms to support synchronization barriers for the ren- 
dezvous of multiple threads in a task executed:in parallel 
are also provided by the broadcast and broadcall facilities in 
the parallel protocol, and by the arbitration messages pro- 
vided by the bus allocation scheme. 


BRIDGES 


The Futurebus+ Working Group has been firmly committed 
to the concept of bridges for many years, and believe that 
bridges are a requirement for any new bus architecture to 
succeed. There is presently an enormous investment made 
in existing bus products. This investment is two dimensional, 
representing a great depth in quantity of systems sold and 
breadth in terms of available functionality within a given bus 
architecture. Since a new bus will not be able to achieve this 
penetration for some time, and furthermore does not wish to 
require previous investment to be written-off,. bridges: pro- 
vide a pragmatic solution to this problem. 


A bridge represents a concept more than a physical imple- 
mentation. The idea is to allow transactions begun on one 
bus to be completed on another with minimal impact on the 
software and hardware of the standard modules on either 
bus. This means more than simply converting protocols. A 
bridge must provide a nearly seamless means of communi- 
cation between what are basically incompatible architec- 
tures. This includes methodologies for defining how inter- 
rupts are handled on a bus which does not recognize the 
single-processor concept of interrupts, for example. 


For Futurebus+, this has been addressed for a number of 
existing and future bus standards. Futurebus+ provides its 
own specifications within the basic protocols to: bridge to 
itself. Bridges have also been defined between Futurebus + 
and VMEBus (IEEE P1014.2), Multibus Il (IEEE P1296.2), 
and the Scalable Coherent Interface (IEEE P1596). Those 
will allow Futurebus+ to be used with existing or future 
hardware and software from any of those bus architectures. 
A smooth upgrade path from lower performance buses to 
higher performance buses is assured, as is the usefulness 
of the newer bus standard even without a broad product line 
in its early days. 


TESTABILITY AND MAINTAINABILITY 


Futurebus+ has been designed from the outset to:make it 
straightforward to build testable implementations. Facilities 
to support error detection go hand in hand with hooks to 
stimulate those mechanisms to deliberately cause an error, 
so that the mechanism may be tested. : , 


Much discussion took place on the need for a boundary 
scan standard (such as IEEE P1149) to be included within 
the Futurebus+ signal set. Since the bandwidth require- 
ments for such a bus are so low, the relative cost of bus 
signal lines is not negligible, it was decided to support these 
facilities through the use of a boundary scan controller on 
the modules themselves (logic is cheap inside LS! devices), 
and to stimulate and control this controller through com- 
mands and telemetry transmitted through the IEEE P1394 
High-Serial Bus mechanism provided on two of the pins of 
the Futurebus+ signal set. 

In addition, IEEE P896.3 may specify a test access port as a 
requirement on the access panel of modules built to a pro- 
file which includes requirements for Maintainability and 
Testability. See IEEE P896.3 for further details. 
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REAL-TIME APPLICATIONS 


Futurebus+ is also designed to support real-time applica- 
tions where the correctness of computation depends upon 
not only the results of the computation but also the time at 
which outputs are generated. Examples of real-time applica- 
tions include air-traffic control, avionics, process control and 
mission critical computations. The measures of merit in a 
real-time system include: 


e Fast response to urgent events and accurate timing in- 
formation. 


High degree of schedulability. Schedulability is the de- 
gree of resource utilization at or below which the dead- 
lines of tasks can be ensured. It can be thought of as 

“real-time throughput”, i.e., the number of timely transac- 
tions per second. 


Stability under transient overload. When the eyatem is 
overloaded by events and it is impossible to meet all the 
deadlines, we must still guarantee the deadlines of se- 
lected critical tasks. 


The distributed clock synchronization protocol defined in 
P896.3 provides users with accurate and reliable timing in- 
formation. The prioritized arbitration message mechanism 
provides the basis of fast response to urgent events. The 
multiple priority levels in the arbitration protocol and the 
consistent handling of priority among arbitration, message 
and DMA protocols provides the user with a consistent and 
powerful scheduling tool. As a result, users can employ ana- 
lytical scheduling algorithms, for example, the rate mono- 
tonic algorithm, to ensure a high degree of schedulability 
and stability. In short, Futurebus+ architecture facilitates 
the development of real-time systems, whose timing behav- 


ior can be analyzed and predicated a-priori. 


FAULT-TOLERANT APPLICATIONS 


Futurebus+ is also designed to be suitable for use in high 
integrity systems: the address/data, command and arbitra- 
tion lines are all protected by a parity bit per byte, there are 
no central elements to adversely affect the survivability of 
the system, and modules can be inserted or removed while 
the system is operating to facilitate high availability applica- 
tions. 


Included in the arbitration protocols and initialization facili- 
ties are the mechanisms to support the live insertion and 
removal of modules. Although Futurebus+ includes the 
necessary hooks. Full specification of how they are used in 
an application system can be found in P896.3. 


PROFILES AND INTEROPERABILITY 


Older bus standards often suffered from interoperability pro- 
lems. Boards from different manufacturers would often not 
communicate with one another. Since this defeats the pur- 
pose of open standard architectures, the Futurebus+ spec- 
ifications have been laid out to maximize interoperability. 
This has been done in three ways: First, the specifications 
have been written in a form which is unambiguous (using 
formal equations where possible rather than purely English 


statements). Second, an adequate amount of background 
description has been provided, to encourage the implemen- 
tor to understand and share in the instinctive elegance of 
the protocols with the original designers of the specifica- 
tions. Third, by providing a hierarchical system of con- 
straints to allow a tradeoff between application specific 
(e.g., low cost versus high performance), and application 
generality without compromising interoperability. This latter 
point has been implemented through the ner of pro- 
files. 


The Futurebus+ family contains a number of specifications 
which do not individually constitute a bus specification, but 
provide a rich set of tools with which to build optimal imple- 
mentations for a wide spectrum of applications. When 
called up within profiles, however, these specifications, and 
the options within them, are much more tightly constrained. 
This is to provide the implementor with clear guidelines, 
which if followed, will maximize interoperability with any oth- 
er implementation which follows the same guidelines. 


As an example, the specifications which may be treated as 
a family for use within a typical Futurebus+ profile are: 
P896.1 Futurebus+ Logical Layer Specifications, P896.2 
Futurebus+. Physical Layer and Profiles, P1194.1.Back- 
plane Transceiver Logic, P1212 CSR Architecture, P1394 
(High speed serial bus), and P896.3: Futurebus+ Systems 
Configuration Guide. 

A profile consists of a mapping of which sections of which 
specifications and which options within those sections are 
appropriate for use together within an implementation. Pro- 
files sanctioned by the Working Group will be contained 
within the P896.2 document, and higher level profiles suit- 
able for specialized system application environments will be 
included within P896.3. This explicit discussion of what is 
required and what is not within a given profile addresses the 
interoperability issues brought about by arbitrary assignment 
of optionality by manufacturers. Profiles also allow the buyer 
of Futurebus+ based products to know exactly what fea- 
tures come with each product. If a manufacturer follows the 
requirements laid out within a profile, that product is much 
more likely to be interoperable with the products of any oth- 
er manufacturer meeting that profile. 
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Futurebus+ Asynchronous 
Slave Memory Design 


INTRODUCTION 


This application note describes a Futurebus+ asynchro- 
nous slave memory board design. Part 1 of this application 
note contains an introduction to Futurebus+ and how the 
.asynchronous slave memory board interfaces to it. Part 1 
then goes into a more detailed description of the 
Futurebus+ slave protocol controller and the control lines 
that interface it to Futurebus+ and the Memory Module. 
Part 2 of this application note describes the Memory Module 
and how the Memory Module Control interfaces between 
the two National Semiconductor DP8422A-25 DRAM con- 
trollers, the two banks of DRAM, and the Futurebus+ slave 
protocol controller. 

This application note implements a Futurebus+ asynchro- 
nous slave memory design (see Figures 7 and 2) using Na- 
tional Semiconductor GAL’s (or PAL’s) to achieve a peak 
transfer rate of 20 mega-transfers/second speed (approxi- 
mately 80 Mbytes/sec using 32 data bits per memory bank 
and 160 Mbytes/sec using 64 data bits per memory bank) 
during compelled burst transfers. The Futurebus+ protocol 
supports the compelled mode of operation. The word com- 
pelied refers to the fact that after the master gives a request 
for a transfer the slave is compelled to provide a response 
before the master can proceed to the next transfer. The 
request/acknowledge protocol is asynchronous and edge 
sensitive where both rising and falling edges are used to 
transfer information. This application note assumes that the 
reader is familiar with the DP8422A-25 DRAM controller, 
GAL/PAL design, and Futurebus+. 


INDEX TO APPLICATION NOTE 


PART 7: FUTUREBUS+ ASYNCHRONOUS SLAVE 
MEMORY DESIGN 


1.0 INTRODUCTION TO FUTUREBUS+ 


2.0 INTRODUCTION TO SLAVE MEMORY BOARD 
DESIGN 


3.0 CONNECTION PHASE 
4.0 DATA PHASE 
4.1 Odd Beat Read Operation 
4.2 Even Beat Read Operation 
4.3 Odd Beat Write Operation 
4.4 Even Beat Write Operation 
4.5 Read Intervention 
4.5.1 Odd Beat Read Intervention 
4.5.2 Even Beat Read Intervention 
4.6 Disconnection Phase 
5.0 FUTUREBUS+ SYSTEM TIMING CALCULATIONS 
5.1 Time from Master Generating AS* to Master Receiv- 
ing Al* 
5.2 Time during Read Access from Master Generating 
AS* to Master Receiving the First Odd Beat DI* 


5.3 Time during Write Access from Master Generating 
AS* to Master Receiving the First Odd Beat DI* 
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5.4 Time during Read Access from Intervention from the 
Master Generating AS* to the Master Receiving the 
First Odd Beat DI* 


5.5 Time Allowed for Master to Generate Odd Beat DS* 
from Reception of Al* 


5.6 Time during Read Access from Master Generating 
DS* to Master Receiving DK* or DI* 


5.7 Time during Write Access from Master Generating 
DS* to Master Receiving DK* or DI* 


5.8 Time during Read Access with Intervention from 
Master Generating DS* to Master Receiving DK* or 
DI* 

5.9 Computation of Delay Necessary for: 
Master to Guarantee Command Setup to AS* 
Master to Guarantee Write Data and Command Set- 
up to DS* 
Slave to Guarantee Status and Capability Setup to 
Al* 
Slave to Guarantee Read Data and Status Setup to 
DK* or DI* 


5.10 Time during Disconnection Phase from Master Re- 
ceiving DK* or DI* (from the last data beat) to the 
Master Receiving AK* Released 


5.11 Example Calculation of a 8 Transfer Burst Transac- 
tion Across Futurebus+ 


6.0 DESIGN CONSIDERATIONS OF THIS 
APPLICATION NOTE 


6.1 Partial Transactions 

6.2 End of Data Status Indication (Out-of-Page) 

6.3 Parity Detection 

6.4 Filtering of Address/Data Synchronization Signals 
6.5 Initial Accesses 

6.6 CSR Space 

6.7 Module Registers 

6.8 Status and Capability Bits 


7.0 PROTOCOL CONTROLLER PAL/GAL INPUT AND 
OUTPUT DEFINITIONS 


7.1 S_GAL1 PAL Inputs 
7.2 S_GAL1 PAL Outputs 
7.3 S_.GAL2 GAL Inputs 
7.4 S__GAL2 GAL Outputs 


PART 2: DESCRIPTION OF MEMORY MODULE DESIGN 


8.0 GENERAL DESCRIPTION 
9.0 DRAM CONTROLLER DESCRIPTION 
(8420__MODULEO, 1) 
10.0 GAL INTERFACE MODULE DESCRIPTION 
(MEM_MODULE_CTR) 
11.0 LATCHED TRANSCEIVER DESCRIPTION 
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12. 0 FUTUREBUS+ MEMORY MODULE DP8422A 


; PROGRAMMING BITS 
13.0 TIMING CALCULATIONS 
~ 14.0 GAL INPUT AND OUTPUT DEFINITION 
14.1 Definition of Memory Module State Variables 
14.2 Definition of Memory Module Control Inputs 
14.3 Definition of Memory Module Control Outputs 
_' 14.4 Definition of Other Signals i in the Beslan 
14.5 Other Signals from MEM__GAL2 
14.6 Other Signals from MEM_GAL3 
14.7 Other Signals from MEM_GAL1 
. 14.8 Other Signals from MEM_GAL4 
and MEM__GAL5 


-15.0GAL EQUATIONS WRITTEN IN ABEL FOR THE 


MEMORY MODULE DESIGN 
PART 1: FUTUREBUS+, THE PROTOCOL 


‘CONTROLLER, AND THE INTERFACE - 


TO THE MEMORY MODULE 


1.0 INTRODUCTION TO FUTUREBUS+ 
Futurebus+ is a high-performance asynchronous 64-bit 


-multiplexed address/data backplane bus designed by the 


IEEE 896.1 committee for use in a wide variety of multipro- 
cessor architectures. The Futurebus+. standard is a next 
generation backplane bus standard developed to a set of 
requirements including openness, performance, and system 
facilities and flexibilities so as to not hinder systems using 
this bus for many generations of computer systems. Future- 


‘bus+_ is a single cache coherent backplane architecture 


featuring scalability, technology independent protocols, and 
explicit provisions to extend to future applications. Require- 


‘ments set for the Futurebus+ . architecture by the IEEE 


896.1 Futurebus+ Working Group include: 
1. Architecture, processor, and technology independent 
2. A basic asynchronous (compelled) transfer protocol 
3. An optional extended source-synchronized protocol 
.No technology-based upper limit to bus performance 
. Fully distributed parallel and arbitration protocols 
. Support for fault-tolerant and high- availability systems 
. Support for cache-based shared memory 
. Compatible message transport definition 


Compatibility of varying speed and technology boards con- 
nected to the same Futurebus+ backplane is dependent 


upon broadcast capability, or a snooping cache coherence 
scheme. The performance of a Futurebus+ backplane is 
scalable over time to allow a low-end 32-bit system operat- 
ing at 100 Mbytes/sec to be expanded to a 256-bit system 
operating at 3.2 Gbytes/sec in the future. This performance 
is attainable by the use of source-synchronized protocols 
which eliminate spatial skews and receivers which are trig- 
gered by the incident wave from the driver. The synchroni- 
zation protocol of the Futurebus+ backplane allows the 
synchronization domain of the sender to extend along the 
backplane, presenting only one synchronization interface 
between the bus and the receiver. 


Futurebus+ uses an evolved version of the Parallel Con- 
tention Arbiter. Through the application of a unique arbitra- 
tion vector to this logic, one contender only will be uniquely 
selected as the winner. This implementation requires no 


‘central logic on the backplane and gains the following ad- 


vantages: 

1. The current master can see any requests and their priori- 
ty and determine whether it should give up the bus 

2. Multiple priority levels, allowing systems to allocate bus 
bandwidth to processors running the most critical tasks 


. 3. A master can be pre-empted by a higher-priority contend- 


er allowing a shorter average latency to.access the bus 


In addition, Futurebus+ has a number of companion stan- 
dards offering bridging. to other backplane and distributed 
buses such as VMEBus (IEEE P1014.2), Multibus I! (IEEE 
P1296.2), and the scocietle Coherent Interconnect (IEEE 


- P1596). 
~ 2.0 INTRODUCTION TO SWE MEMORY 


BOARD DESIGN 


This application note describes a Futurebus+ slave memo- 
ry board (Figures.1 and 2). This memory board (Figure 3) 
incorporates.a GAL based Futurebus+ Protocol Controller 
consisting of two GALs and 6 delay lines (Figure 4), a GAL 
based Memory Module Control unit consisting of five GALs 
and two delay lines (Figure 7), two DP8422A-25 DRAM con- 
trollers (Figure 6), two DRAM memory banks (82 bits each, 
but expandable to 64 bits each along with parity bits, Fig- 
ures 3 and 5), two 74F543 latched transceivers (Figure 3), 
an address latch (Figure 3), an address decoder, two 
DS3884 Handshake Transceivers (Figure 3), and six 
DS3886 BTL Latching Data Transceivers (Figure 3). 
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FIGURE 1. Slave Memory Module Block Diagram 1 
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FIGURE 2. Slave Memory Module Block Diagram 2 
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This Futurebus+ slave memory board can achieve a 20 
mega-transfer/second rate during burst accesses. This per- 
formance is approximately 80 Mbytes/sec using 32 bits per 
memory bank and 160 Mbytes/sec using 64 bits per memo- 
ry bank. This performance is calculated in the timing section 
of this application note (Section 5.0 Futurebus+ System 
Timing). 

A Futurebus+ access to the DRAM of the slave memory 
board can be divided into three operations: The Connection 
Phase, Data Phase, and Disconnection Phase. The Data 


Phase can be further divided into odd or even beat read ° 


operations, odd or even beat write operations, and odd or 
even beat intervention accesses. The odd or even beat op- 
erations of the Data Phase are due to the state of the re- 


quest-acknowledge handshake operation of the Future- 


bus+ protocol and are not to be related to the odd or even 
address banks of DRAM. In other words, a Futurebus+ odd 
beat read access may be an access to the even or odd 
address bank of DRAM, dependent upon the state of the 
least significant double word address bit of the access. 


3.0 CONNECTION PHASE 


Any access to the slave memory board DRAM begins with 
the Connection Phase. The Futurebus+ bus master asserts 


ieee en ~ CONNECT 
rie 7 hes . : ‘ 
& iv 78 aati 4) 
| AS 


ODD BEAT 


AK 

Al 

DS 
DK_OUT 


DILLOUT 


ADD/ 
DATA 


AREQ~ 
DT_STB 
D_ACK 


WR 


address and command lines to access a particular slave 
board or boards and asserts the Address Sync line (AS*) to 
tell the slave boards that the current address and command 
are valid (see Figures 8 or 77). 


Upon seeing AS* asserted, the slave board Protocol Con- 
troller asserts Address Acknowledge (AK*). Each slave 
board latches and decodes the address and generates an 
internal Chip Select (CS ~) signal. If the board is not select- 


. ed, it does not take part during the rest of the current bus 
tenure except by asserting Al* and releasing AK* during the 


Disconnection Phase (see Figure 76). 


- The selected slave board decodes the Futurebus+ com- 


mand, and asserts address status and capability lines on 
the Futurebus+ for the bus master. The slave board will 


‘assert the selected status bit (SL*) if it is selected for the 


current transaction, and will assert the broadcast status bit 
(BC*) if the master is accessing an area of memory held in 


? common with other slave boards, such as the CSR space. 
« “The beat error status bit (BE*) will be asserted if the slave 


board is not capable of executing a command or a address 
or command parity error is detected. The slave memory 
board will also drive the capability bits. The split response 
capability bit (SR*) will be released and the compelled capa- 
bility bit (CO*) will be asserted. 
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FIGURE 8. Slave Memory Read Access Timing 








The Protocol Controller also asserts the Data Acknowledge 
Inverse signal (DI*) on the Futurebus+ to prepare for the 
Data Phase. After a delay to allow for transceiver skew be- 
tween driving the status and capability bits and Al*, the Pro- 
tocol Controller releases Address Acknowledge Inverse 
(Al*). This indicates to the bus master that the status and 
capability information is valid and that the slave (or slaves) 
has completed the connection phase. 


Internal to the slave board, the Protocol Controller gener- 
ates control signals to the Memory Module to cause the 
requested read or write access to take place. The Memory 
Module Control asserts the internal Address Acknowledge 
line (ADD_ACK~) to the Protocol Controller to indicate 
that the DRAM is ready to be accessed. 


The slave memory board then enters the odd beat Data 
Phase. Note that the master may have already entered the 
odd beat Data Phase by asserting DS* but the slave memo- 
ry board will not enter the data phase until ADD_ACK ~ is 
received. 


4.0 DATA PHASE 


The Data Phase consists of odd beat read or write (Figure 
17), even beat read or write (Figure 78), and odd or even 
beat intervention access operations (Figures 19 and 20). 
The Protocol Controller passes WR* to the Memory Module 
to indicate whether the master is requesting a read or write. 
The initial access following the Connection Phase is consid- 
ered odd beat, as indicated by Data Sync (DS*) asserted 
(see Figures 8 or 77). 


The DRAM bank being accessed first (odd or even) is indi- 
cated by the lower address bank select input (B1) from the 
address in the address latch. If AS* becomes released or 
invalid for any reason before entering the odd or even beat 
operations, the board would immediately pass into the Dis- 
connection Phase. 


lf IV* is asserted, the board passes into the Intervention 
access phase. With IV* released and AS* asserted, the 
board passes into either an odd beat read (WR* released) 
or an odd beat write (WR* asserted) operation (Figure 77). 


The Data Sync (DS*) signal from the bus master tells the 
slave that either the write command and data are valid to 
start the write operation or that the read command is valid 
and the master is ready to receive read data. 


The status and capability bits that were driven in the con- 
nection phase are also driven in the data phase before it is 
terminated by the release of DK* or DI*, depending upon 
whether it is the end of an odd or even data beat. The end 
of data status bit (ED*) could also be set, during the data 
phase, if the memory module reads or writes the last double 
word in a page of the DRAM. This bit signals the master that 
no further accesses can take place on the slave board. 


4.1 Odd Beat Read Operation 

With AS*, DI*, and DS* asserted and WR’%, IV*, and DK* 
released, the slave board starts the odd beat read operation 
(see Figures 8, 11, 17). 

If it is the first read access after the Connection Phase, the 
Memory Module performs two operations for the initial odd 
beat read only. The latching data transceivers are turned 
around to transmit onto the Futurebus+ and the Memory 
Module ‘Control is 3 requested to do two read accesses via 
the DT__STB signal. On each subsequent read access 
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(even or odd beat) only one DRAM access will take place. 


That access will be a pipelined read access in preparation 
for the next read request from the master. 

The i initial read access request (DT_ STB asserted) reads 
the data needed for the current read request from the mas- 
ter. Once this data has been accessed (D__ACK asserted) 
the Protocol controller will request another read access 
(DT_STB released) to the next sequential address in prep- 
aration for the next read request from the master (even beat 
read access). 


During an initial read access, the first DT_STB edge will 
always be a rising edge. The DT__STB edge causes the 
Memory Module Contro! to send control signals to the 
DRAM Controller and DRAM so that the addressed data is 
output through the 74F543 transceivers. The internal Data 
Output Acknowledge signal (D__ACK) is then asserted to 
the Protocol Controller from the Memory Module Control. 
When D_ACK transitions,.the data is valid at the slave 
board 74F543 transceivers ready to be clocked out 
(CKO_D_S_C) to Futurebus+ via the DS3886 latching 
transceivers. 

The following actions occur for every odd beat read 
operation: With D_ACK asserted, the requested data and 
status are clocked (CKO__ D_S_C) from the 74F543 
transceivers into the DS3886 latching transceivers and onto 
the Futurebus+. To prepare for the even beat read, DK* is 


asserted. So as to pipeline data for the next read, the Proto- 


col Controller deasserts DT_STB to request the next se- 
quential piece of data from the DRAM (burst access). This 
next piece of data is output into the 74F543 transceivers. If 
this is the initial read operation, F_INITACC ~ is released. 
After a delay ‘tO ‘allow for transceiver skew (between the 
read da ata, s! status on Futurebus+ and DI* released), DI" is i 

released to indicate that the data on the Futurebus+ is 
valid.” 


When the data for the next (even beat) read is valid at the 
74F543 transceivers, D_ACK is deasserted. The board 
now waits for the bus master to release DS* to indicate that 
it is ready for the next piece of ‘data. if AS* is released by 
the master before DS*, the board enters the Disconnection 
Phase. If DS* is released, the board enters the even beat 
read operation. 


4.2 Even Beat Read Operation 


With AS* and DK* asserted and DS*, DI*, WR%*, and IV* 
released, the slave board starts the even beat operation 
(see Figures 8, 11, 18). 

For the even beat-read, the current requested data is valid 
at the 74F543 transceivers and DS* has been released to 
indicate that the bus master is ready to read data. The 
DS3886 transceivers are clocked (CKO__D__S_C) and the 
address and status information is latched in and onto the 
Futurebus+. DI* is asserted to prepare for the odd beat 
operation and DT__STB is asserted to the Memory Module 
Control to read the next piece of sequential data into the 
74F543 transceivers. 


Following a delay to allow for transceiver skew (between 
data, status and DK* released) DK* is released to indicate 
that the next piece of data is valid on the Futurebus+. 
When the data for next (odd beat) read is valid at the 
74F543 transceivers (initiated by the previous DT_STB 
transition), D__ACK is asserted. The board now waits for the 
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bus master to assert DS* to indicate its request for the next 
piece of data. If AS* is released by the master before DS* is 
asserted, the board enters the Disconnection Phase. If DS* 
is asserted, the board enters the odd beat read operation. 


LEIA_D 
F_INITACC~ 


ON BOARD 
DATA 


4.3 Odd Beat Write Operation : 

With AS*, DI*, DS*, and WR* asserted and IV* and DK* 
released, the slave board starts the odd beat write opera- 
tion (see Figures 9, 12, 17). 


Slave Memory Board Write Cycle Timing 
CONNECT ODD BEAT EVEN BEAT 


ODD BEAT EVEN BEAT DISCONNECT 


TL/L/10772-24 


FIGURE 9. Slave Memory Write Access Timing 
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With DS* asserted, indicating that the data on the Future- 
bus+ is valid, the DS3886 latching transceivers latch 
(LEI_A_D) the data to be written into the DRAM. Dk* is 
asserted to prepare for the even beat write operation. 


Status information from the Protocol Controller is clocked 
(CKO__D__S__C) into the latched transceivers (DS3886) 
and onto the Futurebus +. If this is the initial write operation 
F_INITACC ~ is deasserted. 


DI* is then released, after a delay to allow for transceiver 
skew, to acknowledge that the status information is valid on 
Futurebus+ and the write data has been received. 


DT__STB is then asserted to the Memory Module Control to 
write the data latched in the DP3886 latches into the DRAM. 
When the requested write data has been written into the 
DRAM the Memory Module Contro! asserts D_ACK. 


The slave board now waits for the bus master to release 
DS* to indicate that the next piece of data is valid on the 
Futurebus+. If AS* is released by the master before DS*, 
the board enters the Disconnection Phase. If DS* is re- 
leased, the board enters the even beat write operation. 


4.4 Even Beat Write Operation 


With AS*, DK*, and WR* asserted and DS’, DI*, and IV* 
released, the slave board starts the even beat write opera- 
tion (see Figures 9, 12, 18). 

With DS* released indicating that the data on the 
Futurebus+ is valid, the DS3886 latching transceivers 
latch the current data to be written to the DRAM 
(LEI_A_D). DI* is asserted to prepare for the odd beat 
write. Status information from the Protocol Controller is 
clocked (CKO__D__S__C) into the status transceiver an 
onto the Futurebus+. : 


DK* is released, after a delay to allow for transceiver skew, 
to acknowledge that the data has been received and status 
information is valid on Futurebus +. 


DT__STB is deasserted to the Memory Module Control to 
write the data latched in the DP3886 latches into the DRAM. 
When the requested write data has been written into the 
DRAM the Memory Module Control deasserts D__ACK. | 


The board now waits for the bus master to assert DS* to 
indicate that the next piece of data is valid on the Future- 
bus+. If AS* is released before DS* is asserted, the board 
enters the Disconnection Phase. If DS* is asserted, the 
board enters the odd beat write operation. 


4.5 Read Intervention 


When a master performs a read request on Futurebus+ the 
slave memory board that contains this data may not always 
be the board that sources this data back to the master. For 
example, another Futurebus+ cache board may have had a 
copy of the data and changed it (written to it) but has not yet 
written this updated data to the slave memory board. 


Therefore, when the master selects a memory module to 
read a block of data, and a cache on another module sees 
that it has a more up-to-date copy, the cache module will 
intervene in the transaction by diverting the memory module 
and providing the data to both the master and the slave 
memory module. !n this case the slave memory module that 
was going to perform a read access of its memory now 
instead does a write access to write the more up-to-date 
data (from the intervening module) into its memory. In other 
words, the memory module read access has been changed 
into a wire access due to intervention (see Figures 10, 13, 
19, 20). 

During intervention, the changed data is passed to the slave 
board and bus master from the owner and the system 
DRAM is updated with the correct value. To account for this, 
the initial odd beat read operation must not commence until 
it has been determined that the current transaction does not 
involve intervention. For an initial read access, it is assumed 
that the Intervention line (IV*) will be asserted prior to the 
transition of Al* filtered during the Connection Phase. The 
slave memory board of this application note requires that 
the IV* status bit is asserted before the initial assertion of 
DS* at the beginning of the odd data beat. 


This slave memory board supports intervention through the 
intervention status bit (IV*) and does not look at the slave 
write command bit (SW*). This should cause no problems 
using the compelled mode of operation. The reasons that 
the IV* status bit was used instead of the SW* command bit 


- are as follows. First, the IV* status bit will be valid on the 
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Futurebus+ earlier then the SW* bit. !V* will be valid earlier 
on the slave memory board also since the status latch is in 
fall-thru mode until Al* filtered is released. The slave memo- 
ry board does not use Al* filtered released to validate IV*. 
This allows the slave board to guarantee that IV* will be 
valid before DS* is asserted. This leads into the second 
reason which is if SW* was used it would have to be validat- 
ed by DS*. To do this would require an extra delay in the 
first access of every transaction (to account for transceiver 
skew) which would effect system performance. 
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FIGURE 10. Slave Memory Read with Intervention Timing 
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FIGURE 12. Slave Memory Write Access Timing 
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Read Access To Slave Memory Board with Intervention 
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FIGURE 13. Slave Memory Read Access with Intervention Timing 
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FIGURE 14. Slave Memory Read During Refresh Timing 
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The intervention access odd and even beat write is con- 
trolled by the data “owner” module with DK* and DI*. Dur- 
ing odd beats of the intervention access, only the module 
sourcing the data (the data “owner”) initially asserts DK*. 
All other modules wait until they detect DK* asserted before 
asserting their own DK*. During even beats, the data source 
module initially asserts DI* and the other modules wait until 
they detect DI* asserted before asserting their own DI*. 


DK* and DI* input to the slave board from Futurebus+ will 
be denoted DK_IN and DI_IN. DK* and DI* from the slave 
memory board onto the Futurebus+ will be denoted DK 
and DI. The bus master will monitor the open-collector driv- 
en DK* and DI* lines on the Futurebus+ and will not issue 
the next DS* until DK* and DI* have terminated the present 
data beat and the master has received the requested data. 


4.5.1 Odd Beat Read Intervention 


With AS*, IV*, DI*, and DS* asserted, and DK* released, 
the slave board enters the odd beat read intervention oper- 
ation (see Figures 10, 13, 19). \f AS* is released by the 
master before DS*, the board enters the Disconnection 
Phase. 


DS* asserted indicates that the bus master is ready to read 
the data from the Futurebus+ . 


Upon seeing DS* asserted, the intervening module issues 
the first double-word of data onto the Futurebus+. When 
this data is valid on Futurebus+, the intervening module 
asserts DK*. The slave memory board see this as DK_IN 
asserted and responds by asserting DK*. With DK__IN as- 
serted the DS3886 latching transceivers latch (LEi_A__D) 
the data to be written into the DRAM. 


Status information from the Protocol Controller is clocked 
(CKO__D__S__C) into the latched transceivers (DS3886) 
and onto the Futurebus +. If this is the initial access opera- 
tion F_INITACC ~ is deasserted. 


DI* is then released, after a delay to allow for transceiver 
skew, to acknowledge to the master and intervening module 
that the status information is valid on Futurebus+ and the 
write data has been received. 


DT_STB is then asserted to the Memory Module Control to 
write the data latched in the DP3886 latches into the DRAM. 
When the requested write data has been written into the 
DRAM the Memory Module Control asserts D__ACK. 


The board now waits for the bus master to release DS* to 
indicate that the bus master is ready for the next piece of 
data. If AS* is released by the bus master before DS*, the 
slave board and intervening module enter the Disconnec- 


4.5.2 Even Beat Read Intervention 
With AS*, IV*, and DK* asserted, and DS* and DI* re- 


leased, the slave board enters the even beat read interven- 


tion operation (see Figures 10, 13, 20). |f AS* is released by 
the master before DS* is asserted, the board enters the 
Disconnection Phase. 


With DS* released, the intervening module asserts the next 
double-word of data onto the Futurebus +. When the data is 
valid on Futurebus+, the intervening module asserts DI*. 


The slave board sees this as DI__IN asserted and responds 
by asserting DI*. With DI_IN asserted the DS3886 latching 
transceivers latch (LEI_A__D) the data to be written into 
the DRAM. 


- Status information from the Protocol Controller is clocked 


(CKO__D.__S__C) into the latched transceivers (DS3886) 
and onto the Futurebus+. 


Dk* is then released, after a delay to allow for transceiver 
skew, to acknowledge to the master and intervening module 
that the status information is valid on Futurebus+ and the 
write data has been received. 

DT_STB is then deasserted to the Memory Module Control 
to write the data latched in the DP3886 latches into the 
DRAM. When the requested write data has been written into 
the DRAM the Memory Module Control deasserts D__ACK. 


The board now waits for the bus master to assert DS* to 


- indicate that the bus master is ready for the next piece of 


tion Phase. If DS* is released, the board enters the even — 


beat read intervention phase. 
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data. If AS* is released by the bus master before DS* is 
asserted, the slave board and intervening module enter the 
Disconnection Phase. If DS* is asserted, the board enters 
the odd beat read intervention phase. 


4.6 Disconnection Phase 


The bus master releases AS* to indicate to the participating 
slaves that the transaction is being terminated (see Figures 
8, 11, 27). 


Upon detecting AS* released, the slave board, evaluates 
the command lines and asserts Al* and deasserts DK* and 
DI* on the Futurebus+. Internal to the slave board, 
DT__STB is deasserted. The DS3886 latching transceivers 
are opened and the address latch is set to fall-through, pre- 
paring the slave board to sense and analyze the next ad- 
dress asserted on the Futurebus+. The status and capabili- 
ty from the Protocol Controller are clocked onto the Future- 
bus+ for the bus master to analyze. Finally, as soon as the 
memory module has finished reading or writing data from 
the previous data beat the slave board releases AK* and 
the transaction ends. The slave board is now ready to enter 
the Connection Phase for the next transaction. 











Initlal Condition 
AS 
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Latch Address and Command (!LEILADD_CM) 
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Ube, sl, Isr, co] 


=Deassert sl status bit if the slave memory board Is not selected 
“Assert be status bit if Futurebus# command Is not possible 


Drive ILEI_A_D 
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Drive !AREQ~ to start DRAM access* 


Drive !al, 

Drive ILEI_S_C If lai (f) received. 
This latches the status from 
Futurebus+. 


7 re 


NO YES 


DISCONNECT PHASE ODD BEAT DATA PHASE 


*Note that the predecessor to AREQ~ 
(AREQA~) is initiated from AS at the beginning 
of the connection phase. 


NO 


TO 
DISCONNECTION 
PHASE 
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FIGURE 16. Connection Phase State Diagram 
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TL/L/10772-32 
FIGURE 17. Odd Beat Data Phase State Diagram 
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FIGURE 18. Even Beat Data Phase State Diagram 
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FIGURE 19. Odd Beat Intervention State Diagram 
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FIGURE 20. Even Beat Intervention State Diagram 
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FIGURE 21. Disconnect Phase State Diagram 
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5.0 FUTUREBUS+ SYSTEM TIMING CALCULATIONS 


5.1 Maximum time from the master generating AS* to the 
master receiving Al* is 116 ns. 


(In nano-seconds) 
Parameter 
(Maximum Delays) Single {| Total 
Delay Delay 


Master’s PAL Produces AS* 
(Assume 10 ns PAL) 

Master’s Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 
Delay Line (+ 2 ns), 40 ns Tap *** 
Slaves PAL Produces Al* 
(Assume 10 ns PAL) 

Slaves Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Masters Handshake Transceiver 
(DS3884 Filtering Al* with Glitch 
Reject Filter of 10 ns, Cn = 10) 


Typical time from the master generating AS* to the master 
receiving Al* is 89 ns. 


(In nano-seconds) 


Single Total 
Delay Delay 


Parameter 
(Typical Delays) 


Master’s PAL Produces AS* 
(Assume 110 ns PAL) 

Master’s Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 

Delay Line (+ 2 ns), 40 ns Tap *** 
Slaves PAL Produces Al* 
(Assume 10 ns PAL) 

Slaves Handshake Transceiver 


Masters Handshake Transceiver 
(DS3884 Filtering Al* with Glitch 
Reject Filter of 10 ns, Cn = 10) 


***The 40 ns Delay is composed of a 30 ns delay that is used to determine 
whether the slave memory board is selected for the current access. At this 
time the status and capability bits are also driven out to the Futurebus+. 
The next 10 ns delay is used to delay Al* from the slave memory board to 
guarantee that the status and capability are valid before asserting Al’. 





5.2 Maximum tlme during a read access from the master 
generating AS* to the master receiving DI* is 359 ns. 
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(In nano-seconds) 
Parameter 
(Maximum Delays) Single | Total 
Delay Delay 


Master’s PAL Produces AS* 
(Assume 10 ns PAL) 

Master's Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 

Two Clocks Maximum to Produce 
AREQ~ 

Slaves PAL Produces AREQ ~ 
(Assume 10 ns PAL) 

Two Clocks at 25 MHz (used in 
Generating ADD_ACK ~ ) 
Memory Module Control Producing 
ADD_ACK~ from PAL 


<- The odd beat DS* from the master must have been 
received by this time or it will become the determining 
factor in the maximum time to DI* (see 5.5 below). 


(In nano-seconds) 


Parameter 
(Maximum Delays, continued) 
Delay Delay 
Slave Protocol Controller Drives 10 
DT__STB to Memory Module 
(Assume 10 ns PAL) 
Initial Read Access DT_STB to 94 
D_ACK, (see Part 2 of This 
Application Note, Memory Module 
Design Section 4.2). 
Delay Line (+ 2 ns), 10 ns Tap 12 
Slaves PAL Drives DI* 10 
Slaves Handshake Transceiver 7 
(DS3884) 
Futurebus+ Delay 7.5 
Master’s Handshake Transceiver 7 
(DS3884) 
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Typical time during a read access from the master gener- jaximum time during a write access from the ue * ) ; 
ating AS* to the master receiving DI* is 287 ns. = AS* to the master receiving DI* is 255 ns. . = 


gn 


(In nano-seconds) Bape seca ea 


aan Parameter 
(Typical Delays) Single Total (Maximum Delays) 
Delay Delay asa 


|Master’s PAL Produces AS* : Master’s PAL Produces AS* 


(Assume 10 ns PAL) (Assume 10 ns PAL) 

Master’s Handshake Transceiver Master’s Handshake Transceiver 
(DS3884) (DS3884) 

Futurebus+ Delay ; Futurebus+ Delay 

Slaves Handshake Transceiver Slaves Handshake Transceiver 
(DS3884) ; (DS3884) ; 
One and One Half Clocks Typical to Two Clocks Maximum to Produce 
Produce AREQ ~ AREQ~ 

Slaves PAL Produces AREQ~ Slaves PAL Produces AREQ~ 
(Assume 10 ns PAL) : (Assume 10 ns PAL) 

Two Clocks at25MHz(usedin ~ | | Two Clocks at 25 MHz (used in 
Generating ADD__ACK ~) ee eee ee Generating ADD_ACK~) 


Memory Module Control Producing — Memory Module Control Producing 
ADD_ACK ~ from PAL ADD_ACK~ from PAL 


<— The odd beat DS* from the master must have been <— The odd beat DS* from the master must have been 


received by this time or it will become the determining received by this time or it will become the determining 
factor in the typical time to DI* (see 5.5 below). factor in the maximum time to DI* (see 5.5 below) | 


(In nano-seconds) Paraineter (In nano-seconds) 


Parameter 
(Typical Delays, continued) Single | Total (Maximum Delays, continued) Single 
my , Delay Delay Delay Delay 
Delay Line (+ 2ns),10nsTap ; 


Slave Protocol Controll ive 
ave Protocol Controller Drives Slaves PAL Drives DI* 


DT__STB to Memory Module . 
(Assume 10 ns PAL) Slaves Handshake Transceiver 


Initial Read Access DT__STB to : pS + Dela 

D_ACK, (see Part 2 of This ; | y 

Application Note, Memory Module 7 Master’s Handshake Transceiver 

Design Section 4.2) _ pats (DS3884) 

Delay Line (+ 2 ns) 10 ns Tap Typical time during a write access from the master gener- 
Slaves PAL Drives DI* vege” |e ating AS* to the master receiving DI* is 202 ns. 

Slaves Handshake Transceiver : = 
(DS3884) (In nano-seconds) 


Futurebus+ Delay ik erlaied oe ; Single | Total 
Master’s Handshake Transceiver : (type oye) Del Del 
(DS3884) . = = 


Master’s PAL Produces AS* 
(Assume 10 ns PAL) es 
Master’s Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 

One and One Half Clocks Typical to 
Produce AREQ~ 

Slaves PAL Produces AREQ~ 
(Assume 10 ns PAL) 

Two Clocks at 25 MHz (used in 
Generating ADD_ACK ~) 
Memory Module Control Producing 
ADD_ACK ~ from PAL 
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<— The odd beat DS* from the master must have been 
received by this time or it will become the determining 
factor in the typical time to DI* (see 5.5 below) 

(In nano-seconds) 
Parameter 
(Typical Delays, continued) Single Total 
Delay Delay 

10 


Delay Line (+ 2ns), 10 ns Tap 
Slaves PAL Drives DI* 

.| Slaves Handshake Transceiver 
(DS3884) 
Futurebus+ Delay 
Master’s Handshake Transceiver 
(DS3884) 


_5.4 Maximum time during a read access with interven- 
tlon from the master generating AS* to the master receiving 
DI* is 359 ns. 


(in nano-seconds) 


Single Total 
Delay Delay 
10 


Parameter 
(Maximum Delays) 


Master’s PAL Produces AS* 
(Assume 10 ns PAL) 

Master’s Handshake Transceiver 
(DS3884) — 
Futurebus + Delay 

Slaves Handshake Transceiver 
(DS3884) 

Two Clocks Maximum to Produce 
AREQ~ 

Slaves PAL Produces AREQ~ 
(Assume 10 ns PAL) 

Two Clocks at 25 MHz (used in 
Generating ADD_ACK ~) 
Memory Module Control Producing 
ADD__ACKL~ from PAL 


<— The odd beat DK* from the intervening module must 
have been received by this time or it will become the 
determining factor in the maximum time to DI*. 


(In nano-seconds) 
Parameter 
(Maximum Delays, continued) | Single | Total 
Delay Delay 


Slave Protocol Controller Drives 

DT__STB to Memory Module 

(Assume 10 ns PAL) 

Initial Read Access DT__STB to 
|D__ACK, (see Part 2 of This ; 

Application Note, Memory Module 

Design Section 4.2) 

Delay Line (+ 2ns), 10 ns Tap 

Slaves PAL Drives Dl* 

Slaves Handshake Transceiver 

(DS3884) 

Futurebus+ Delay 


Master’s Handshake Transceiver 
l (DS3884) 





Typical time during a read access with intervention from 
the master generating AS* to the master receiving DI* is 
287 ns. 


(In nano-seconds) 
Parameter 
(Typical Delays) Single | Total 
pecul Delay | Delay 


Master’s PAL Produces AS* 
(Assume 10 ns PAL) 

Master’s Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 

One and One Half Clocks Typical to 
Produce AREQ ~ 

Slaves PAL Produces AREQ ~ 
(Assume 10 ns PAL) 

Two Clocks at 25 MHz (used in 
Generating ADD_ACK ~) 
Memory Module Control Producing 
ADD__ACK ~ from PAL 


<— The odd beat DK* from the intervening module must 
have been received by this time or it will become the 
determining factor in the typical time to DI*. 


(In nano-seconds) 
Parameter 
Single Total 
Delay 
7 


(Typical Delays, continued) 
Delay 


Slave Protocol Controller Drives 180 
DT__STB to Memory Module 

(Assume 10 ns PAL) 

Initial Read Access DT_STB to 78 
D_ACK, (see Part 2 of This 

Application Note, Memory Module 

Design Section 4.2) 

Delay Line (+ 2.ns), 10 ns Tap 10 
Slaves PAL Drives DI* 7 
Slaves Handshake Transceiver 5 
(DS3884) 

Futurebus+ Delay 2 
Master’s Handshake Transceiver 5 
(DS3884) 
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™, 


5.5 Maximum time allowed (worst case conditions) for 
the master to generate odd beat DS* from the reception of 
Al* to guarantee that the maximum time from AS* to master 
generating the even beat DS* (calculated above in 5.2 and 
5.3) is accurate. 
Point in time where odd beat DS* must be valid 
(see Sections 5.2 and 5.3 above) 
Maximum time from AS* to masters reception of 
Al * (see Section 5.1 above) 
Masters Handshake Transceiver (DS8334) 
Futurebus+ Delay 
Slaves Handshake Transceiver (DS3884) 


Maximum time for master to generate odd beat 
DS* from the masters reception of Al* 74ns 


Maximum time allowed (typical conditions) for master to 
generate odd beat DS* from the reception of Al* to guaran- 
tee that the typical time from AS* to master generating the 
even beat DS* (calculated above in 5.2 and 5.3) is accurate. 


211.5 


—116 
—7 
—-7.5 
—7 


Point in time where odd beat DS* must be valid 
(see Sections 5.2 and 5.3 above) 

Typical time from AS* to masters reception of 
Al* (see Section 5.1 above) 

Masters Handshake Transceiver (DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver (DS3884) 


Typical time for master to generate odd beat 
DS* from the masters reception of Al* 72 ns 


5.6 Maximum time during a slave read access (master 
write access) from the master generating DS to the master 
generating the next edge of DS is 89 ns. This is based on 
the assumption that the DT_.STB request/D__ACK ac- 
knowledge between the protocol controller and the memory 
module (of the I/O board) will be less than or equal to the 
speed of the Futurebus + request/acknowledge handshake 
signals (DS, DK, and DI). 


173 


—89 
—5 
—2 
—5 


(In nano-seconds) 
Parameter 
(Typical! Delays) Single | Total 
Delay Delay 


Master’s GAL Generates DS 
(Assume 10 ns GAL) 

Master’s Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 
Clock Out to Futurebus+ Next Piece 
of Data to Write 

Delay Line (+2 ns), 10 ns tap*** 
Slaves GAL Produces DK or DI 
(Assume 10 ns GAL) 

Slaves Handshake Transceiver, 
DK/DI (DS3884) 

Futurebus+ Delay 

Master’s Handshake Transceiver, 
DK/DI (DS3884) 

Delay Line (+2 ns), 10 ns tap*** 
Master’s GAL Generates DS 
(Assume 10 ns GAL) 


Typical time during a slave read access (master write 
access) from the master generating DS to the master gen- 
erating the next edge of DS is 58 ns. 


***The 10 ns delay line used to compensate for possible skew between the 
Latched Transceiver (DS3886) and the Handshake Transceiver (DS3884). 
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(In nano-seconds) 


Single Total 
Delay Delay 


Parameter 
(Typical Delays) 


Master’s GAL Generates DS* 
(Assume 10 ns GAL) 

Master’s Handshake Transceiver, 
DS (DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver, 
DS (DS3884) 
Clock Out to Futurebus+ Next Piece 
of Data to Write to the Master 
Delay Line (+2 ns), 10 ns Tap*** 
Slaves GAL Produces DK or DI 
(Assume 10 ns GAL) 

Slaves Handshake Transceiver, 
DK/DI (DS3884) 

Futurebus+ Delay 

Master’s Handshake Transceiver, 
DK/DI (DS3884) 

Delay Line (+2 ns), 10 ns Tap 
Master’s GAL Generates DS 
(Assume 10 ns GAL) 


This gives a typical transfer rate of greater than 17 
Mega-Transfers/second during the Data Phase of the 
Futurebus+ Transfer. 


5.7 Maximum time during a slave write access (master 
read access) from the master generating DS to the master 
generating the next edge of DS is 89 ns. This is based upon 
the assumption that the DT_.STB request/D.__.ACK ac- 


_ knowledge between the protocol controller and the memory 


module (of the I/O board) will be less than or equal to the 
speed of the Futurebus+ request/acknowledge handshake 
signals (DS, DK, and DI). 


(In nano-seconds) 

Parameter ; 
(Typical Delays) Single | Total 
Delay Delay 


Master’s GAL Generates DS 
(Assume 10 ns GAL) 

Master’s Handshake Transceiver, 
DS (DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver, 
DS (DS3884) : 
Delay Line (+2 ns), 10 ns Tap*** 


‘|Slaves GAL Produces DK or DI 


(Assume 10 ns GAL) 

Slaves Handshake Transceiver, 
DK/DI (DS3884) 

Futurebus+ Delay 

Master’s Handshake Transceiver, 
DK/DI (DS3884) 

Clock Out to Futurebus+ Next Piece 
of Data to Write to the Slave 
Delay Line (+2 ns), 10 ns Tap*** 
Master’s GAL Generates DS 
(Assume 10 ns GAL) 


***The 10 ns delay line used to compensate for possible skew between the 
Latched Transceiver (DS3886) and the Handshake Transceiver (DS3884). 








Typical time during a slave write access (master read 
access) from the master generating DS to the master gen- 
erating the next edge of DS is 58 ns. 


(In nano-seconds) 
Parameter 
(Typical Delays) Single | Total 
Delay Delay 


Master’s GAL Generates DS 
(Assume 10 ns GAL) 

Master's Handshake Transceiver, 
DS (DS3884) 

Futurebus + Delay 

Slaves Handshake Transceiver, 
DS (DS3884) 

Delay Line (+2 ns), 10 ns Tap*** 
Slaves GAL Produces DK or DI 
(Assume 10 ns GAL) 

Slaves Handshake Transceiver, 
DK/D! (DS3884) 

Futurebus+ Delay 

Master’s Handshake Transceiver, 
DK/DI (DS3884) 

Clock Out to Futurebus+ Next Piece 
of Data to Write to the Slave 
Delay Line (+2 ns), 10 ns Tap*** 
Master’s GAL Generates DS 
(Assume 10 ns GAL) 


This gives a typical transfer rate of greater than 17 
Mega-Transfers/second during the Data Phase of the 
Futurebus+ Transfer. 

***The 10 ns delay line used to compensate for possible skew between the 
Latched Transceiver (DS3886) and the Handshake Transceiver (DS3884). 
5.8 Maximum time during read accesses with interven- 
tlon (master must use filtered DK* and DI*) from the master 
generating DS* to the master receiving DK* or DI* is 


129.5 ns 
(In nano-seconds) 
Parameter 
(Maximum Delays) Single | Total 
Delay Delay 


Master’s PAL Generates DS* 
(Assume 10 ns PAL) 

Master's Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Intervening Module Handshake 
Transceiver 

Delay Line (+ 21s), 10 ns tap *** 
Intervening Module PAL Produces 
DK* or DI* (Assume 10 ns PAL) 
Intervening Module Handshake 
Transceiver — . 
Futurebus+ Delay 
Slaves Handshake Transceiver 
(DS3884) 

Delay Line (+ 2 ns), 10 ns tap *** 
Slaves PAL Produces DK* or DI* 
(Assume 10 ns PAL) 

Slaves Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Masters Handshake Transceiver 
(DS3884 Filtering DI* or DK* with 
Glitch Reject Filter of 10 ns, 
(Cn = 10) 
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Typical time during read accesses with intervention 
from the master generating DS* to the master receiving 
DK* or DI* is 88 ns. 


(In nano-seconds) 


Single Total 
Delay Delay 


Parameter 
(Typical Delays) 


Master’s PAL Generates DS* 

(Assume 10 ns PAL) 

Master’s Handshake Transceiver 

(DS3884) 

Futurebus + Delay 

Intervening Module Handshake 

Transceiver 

Delay Line (+ 2 ns), 10 ns tap *** 

Intervening Module PAL Produces 

DK* or DI* (Assume 10 ns PAL) 

intervening Module Handshake 

Transceiver 

Futurebus Delay + - 

Slaves Handshake Transceiver 

(DS3884) 

Delay Line (+ 2ns), 10 ns tap *** 

Slaves PAL Produces DK* or DI* 

(Assume 10nsPAL) - 

Slaves Handshake Transceiver 

(DS3884) 

Futurebus+ Delay 

Masters Handshake Transceiver 

(DS3884 Filtering DI* or DK* with 

Glitch Reject Filter of 10 ns, 

Cn = 10) 

***The 10 ns delay line used in the slave and intervening module board is 
needed to provide for the skew between the latched transceivers (DS3886) 
and the handshake transceiver (DS3884). This allows the slave and interve- 


ing module board to guarantee that the read data or status is valid on the 
Futurebus+ by the time DK* or DI* is valid on Futurebus+. 





899-NV 


AN-668 


5.9 Computation of the Delay Necessary to Allow 
a. Master to guarantee the command setup to AS* or; 


b. Master to guarantee the write data and command setup 
to DS* or; 


c. Slave to guarantee status and capability. setup to Al* or; 


d. Slave to guarantee read data and status setup to DK* or 
DI*. 


Maximum clock to data valid on Futurebus + 
through the DS3886 latched transceiver 
Minimum handshake signal 
(AS*, AK*, Al*, DS*, DK*, DI*) 
into output valid on Futurebus + 
through the DS3884 handshake transceiver 
Assumed Maximum skew between outputs 
on the PAL22V10-10 (10 ns 22V10, 
“CKO_D._S__C” clock for data, 
status and capability out to Futurebus + 
versus ““DK*, DI* and Al*’’) 


Delay line necessary to guarantee data, 

status, capability and command setup to 

AS*, AK*, Al*, DS*, DK* and DI* : 10 ns 
***Note that this application note uses a 10 ns delay line. Delay lines gener- 
ally have a 2 ns, +5%, whichever is greater skew specification. Therefore, a 
10 ns delay line can only guarantee an 8 ns delay. In the worst case timing 
this would not be acceptable. In this case a 12 ns delay line should be used 
for the AS, DS, DK_IN, DI_IN, and F_ACK delay lines (see Figure 4). 
5.10 Disconnection Phase, Maximum time from the mas- 
ter receiving DK* or DI* (from the last data peal) to the 
master receiving AK* released is 116 ns. 


—3.5Nns 


(In nano-seconds) 
Parameter 
(Maximum Delays) Single | Total 
Delay Delay 


Masters delay line (+ 2 ns) 10 ns 
tap. Note that AS* is being produced 
from the reception of the slave DK* 
or DI* , 
Master’s PAL Produces AS* 
(Assume 10 ns PAL) 

Master’s Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 

Delay Line (+ 2 ns) 30 ns Tap *** 
Slaves PAL Produces AK* (Assume 
10 ns PAL) 

Slaves Handshake Transceiver 
(DS3884) 

Futurebus+ Delay 

Masters Handshake Transceiver 
(DS3884 Filtering AK* with Glitch 
Reject Filter of 10 ns, Cn = 10) 


Disconnection Phase, Typical time from the master re- 
ceiving DK* or DI* (from the last data beat) to the master 
receiving AK* released is 89 ns. . 


(In nano-seconds) 


Single Total 
Delay | - Delay 


Parameter 
(Typical Delays) 


Masters delay line (+ 2ns) 10 ns 
tap. Note that AS* is being produced 
from the reception of the slave DK* 
or DI* 

Master’s PAL erode AS* 
(Assume 10 ns PAL) . 

Master's Handshake Transceiver 
(DS3884) : 
Futurebus+ Delay 

Slaves Handshake Transceiver 
(DS3884) 

Delay Line (+ 2 ns) 20 ns tap *** 
Slaves PAL Produces DK* or DI* 
(Assume 10 ns PAL) 

Slaves Handshake Transceiver 
(DS3884) . 

Futurebus+ Delay 

Masters Handshake Transceiver 
(DS3884 Filtering AK* with Glitch 
Reject Filter of 10 ns, Cn = 10) 


***The 30 ns delay was used to guarantee that the slaves status is valid 
before AK* is released on Futurebus+ . Notice that AK* is in a different GAL 
(S__GAL2) then the signal that is clocking the status out to the Futurebus + 
(CKO__D__S_.C in S__GAL1). A 20 ns delay is needed to offset the skews 
between the two different GALs and the data transceiver (DS3886) verses 
handshake transceiver (DS3884). Since no more inputs could fit on 
S_.GAL1 a 30 ns delay had to be used. 

5.11 Example calculation of maximum and typical time 
of a 8 transfer burst transaction between a master and 
the slave memory board. 


Maximum time calculation for 8 transfer burst read 
transfer across Futurebus+ is 1000 ns: 


’ (In | (In nano-seconds) | 
Parameter 


(Maximum Delays) 


Single | - Total 
at ——s 


Maximum Time for Read Access AS* 
to DI* (Section 5.2, this Includes the 
First Transfer) 

Maximum Time of Next 7 Read 
Access Transfers (Section 5.6, DS* 
to DK* or DI* received, 7 x 75 ns) 
Maximum Time of Disconnected 
Phase, DK* or DI* Received to AK* 
Released (Section 5.10) a 














Typical time calculation for 8 transfer burst read trans- 


20,10 PIT /s 


fer across Futurebus+ is 712 ns. 
(In nano-seconds) 


< 

x, 
Single Total 
Delay an 


Typical Time of Read Access AS* to \ 287 
89 712 


Parameter 
(Typical Delays) 


DI* (Section 5.2, this Includes the 
First Transfer) 

Typical Time of Next 7 Read Access 
Transfers (Section 5.6, DS* to DK* 
or DI* Received, 7 x 48 ns) 

Typical of Disconnect Phase, DK* or 
DI* Received to AK* Released 
(Section 5.10) 


6.0 DESIGN CONSIDERATIONS OF THIS APPLICATION © 


NOTE 


This Futurebus+ slave memory board was designed and 
simulated but it has not been built and tested in a real Futu- 
rebus+ system. Though this board was designed to go into 
a Futurebus+ system there are several modes of operation 
that have not been supported. 


6.1 Partial Transactions, 


The ‘compelled read ‘(or write) partial transaction has not 
been supported in this application. This could be designed 
into this application but would further complicate the PAL 
equations. Also a partial read could perform a double-word 
read without any problems. 


To do a partial write a double-word read could be performed 
first. The byte (or bytes) to be written could then be written 
into the double-word in the masters board. A double-word 
write could then be performed. 


6.2 End of Data Status Indication (Out-of-Page) 


This board does not have a page comparitor built into it. 
This would be needed if the master has the possibility of 
continuing to read or write beyond the end of a page (incre- 
menting beyond a DRAM column address of all ones). 


This could be designed by using a loadable counter that 
could be incremented by one for each DRAM access. If the 
master read or wrote the last double-word in a page of 
DRAM the end of data status bit (ED*) would be set to end 
that transaction. 


6.3 Parity Detection 


Though this application does not show any parity detection 
circuitry this could easily be added. This circuitry would 
probably appear as parity check circuitry only on data being 
written to the slave memory board. In order to keep the 
board performance as high as possible the parity check in- 
formation would lag the data being written to memory by 
one bus beat. In other words, the parity check information 
would influence the Status bits during the next consecutive 
bus. beat. 


6.4 Filtering of Address/Data Synchronization Signals 
This board does not use filtered versions of the address or 
data synchronization signals (AS*, AK*, DS*, DK*, DI*). Al* 
filtered is used to latch the input status and capability from 
Futurebus+., 
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The slave memory board does filter DK* and DI* in the 
PALs for glitches up to 8 ns using : a 10 ns delay line 
(+ 2ns). This is necessary during read accesses with inter- 
vention or during broadcast or broadcall transactions. If the 
slave board needs glitch filtering greater then 8 ns (worst 
case) the filtered versions of DK* and DI* must be used 
from the handshake transceivers (0S3884). Note that this 
would slow.down all accesses on Futurebus+ and hurt the 
performance of this board. For example, it would add an 
additional 11 ns (18-7) worst case for 10 ns glitch filtering, 
Cn = 10. 


6.5 Initial Accesses 


The initial accesses may seem slow. There are several rea- 
sons behind this issue. Once the slave memory board 
knows that it is chip-selected it starts a memory access. But 
it must synchronize the first memory access to the on-board 
clock of 25 MHz (two flip-flops, 80 ns maximum). Also dur- 
ing read accesses the slave memory board cannot start the 
access until it is known whether intervention may occur or 
not. This is not known until DS* is asserted. If not for this 
requirement the memory board could start the initial read 
access earlier thereby perhaps shortening the initial read 
access. 


The synchronization of the initial access could be accom- 
plished faster using a synchronizing D-Type Flip-Flop with 
metastable immune characteristics, such as the 74F5074. 
With ith only c one Flip-Flop synchronizing stage, utilizing the 
74F5074, the initial access would gain approximately one 
clock period (see Figure 34). 


6.6 CSR Space 
This was not dealt with in this application note. 


6.7 Module Registers 


Even though all the Module Registers were not simulated it 
is assumed that they existed in this application note. This 


Registers, and the Module e Status Registers. 


6.8 Status and Capability Bits 


In Figure 3 the selected bit is shown being output to the 
Futurebus+. from the DS3884 Handshake transceiver. Ac- 
tually this application note assumes that all status and capa- 
bility bits are clocked out to the Futurebus + ‘through a 
DS3886. Latched Data transceiver by the signal 
CKO_—D_S_C. Though this transceiver was not shown 
in the simulation block diagrams of Figures 3~7, the 
assumed connection diagram can be seen in Figure 35. 


7.0 PROTOCOL CONTROLLER PAL/GAL INPUT AND 
OUTPUT DEFINITIONS . 


In this section inputs and outputs of the PALs/GALs are 
designated as active low by a trailing “~” (ex. ADD. 
ACK~). An active low signal is valid when it is low, or logic 
0. An active high signal is designated by not ending with a 
trailing ““~” (ex. WR). An active high signal is valid when it 
is high, or logic 1. 


7.1 S__GAL1 Inputs 


CS_AS~ Indicates that a Chip-Selected Address 
Synchronization access request has 
been received from Futurebus+ when 
asserted. 
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ADD_ACK ~ 


ADD_ADD.__10~ 


D_ACK = 


A latched and inverted version of the 
WRite command (SR*) from Future- 
bus+. This command indicates that a 
write access is in progress when assert- 
ed and is held latched until AS* is re- 
leased. 


A inverted version of the InterVention 
(IV*) status bit from Futurebus+. When 
this bit is asserted during a read access 
it indicates that another module is inter- 
vening in the current access and provid- 
ing the data. The slave memory module 
will perform a write access, in order to 
update the memory with the correct 
data, instead of performing the request- 
ed read access. See Section 4 for more 
information. . 7 

ADDress Acknowledge from the memo- 
ry module. This input (when asserted) 
indicates that the DRAM is ready to be 
read or written. 

A delayed version of ADD_ACK~ by 
10 ns. 


The Futurebus + protocol controller AC- 


‘Knowledge. This is a signal from the 


memory module indicating that the cur- 


‘. rent read or write access request 
‘ (DT__STB) from the protocol! controller 


D_ACK_10 | 
DK_IN 


has been accomplished. This is an edge 
sensitive signal. In other words, both the 
rising and falling edges indicate a re- 


‘sponse from the memory module. 


DT__STB and D_ACK form a request/ 
acknowledge type of handshake. 

A 10 ns delayed version of D__ACK. 

A received inverted version of the Futu- 
rebus+ Data acKnowledge (DK*). This 
is needed during accesses with inter- 
vention to tell the protocol controller 
when it is allowed to drive its DK* signal. 


‘See Section 4 for more information. 


"” The Futurebus+ Dk* input inverted and 


delayed by 10 ns. 


A_ received inverted version of the 
Futurebus+ Data acknowledge Inverse 


_ (DI*). This is needed during accesses 


DII_10 


AS_30 
AS__40 


F_LINITACC~* 


with intervention to tell the protocol con- 
troller when it is allowed to drive its DI* 
signal. See Section 4 for more informa- 
tion. 

The Futurebus + DI” input inverted and 
delayed by 10 ns. 

The Futurebus+ AS* input inverted and 
delayed by 30 ns. 

The Futurebus+ AS* input inverted and 
delayed by 40 ns. ; 

A signal indicating the initial Future- 
bus+ access when asserted. This input 
is deasserted during the first access. 
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DS 
DS_.10 


The Futurebus+ DS* input inverted. 


The Futurebus+ DS* input inverted and 
delayed by 10 ns. ; 


7.2 S__GAL1 Outputs 


Al 


DT_STB 


DI 


DK 


Address acknowledge Inverse (inverted) 
output to the Futurebus+ Al* signal. 


The access request (read or write) sig- 
nal from the protocol controller. to the 
memory module. This is an edge sensi- 
tive signal. In other words, both the ris- 
ing and falling edges indicate a DRAM 
request to the memory module. 
DT__STB and D_ACK form a request/ 


acknowledge type of handshake. — 


The Latch Enable for Input Address and 
Data from Futurebus+. This is an input 
to the DS3886 latched data transceivers 
and allows the address or data from the 
Futurebus+ to be enabled (when as- 
serted) or latched (deasserted). 


- The ClocK for Data, Status, and Capabil- 


ity bits. This is-an input signal to the 
DS3886 latched data transceivers and 
clocks data, status and capability bits 
out to Futurebus+ on the rising edge. 


Data acknowledge Inverse (inverted) 
output to the Futurebus+ DI* signal. 
Data acKnowledge (inverted) output to 
the Futurebus+ DK* signal. 


7.3 S_GAL2 Inputs 


CLK 


AS 
CS~ 


WR 


ADD_ACK~ 


The 25 MHz on-board system clock for 
the DP8422A-25 DRAM controller. 


The inverted AS* from Futurebus+. 


Indicates that a Chip-Selected Future- 
bus+ address is asserted. 


A latched and inverted version of the 
WRite command (WR*) from Future- 
bus+. This command indicates that a 
write access is in progress when assert- 
ed and in held latched until AS* is re- 
leased. 


An inverted version of the InterVention 
(IV*) status bit from Futurebus +. When 
this bit is asserted during a read access 
it indicates that another module is inter- 
vening in the current access and provid- 
ing the data. The slave memory module 


’ will perform a write access, in order to 


update the memory with the correct 
data, Instead of performing the request- 
ed read access. See Section 4 for more 
information. 

ADDress Acknowledge from the memo- 
ry module. This input (when asserted) in- 
dicates that the DRAM is ready to be 


read or written. 











Address acknowledge Inverse (inverted) 
output to the Futurebus+ Al* signal. 


A received inverted version of the 
Futurebus+ Address acknowledge In- 
verse (Al"*) filtered. This is needed dur- 
ing accesses with intervention, broad- 
cast or broadcall to tell the protocol con- 
troller when it is allowed to latch the 
status and capability bits input from Fu- 
turebus +. 

The Futurebus+ AS* input inverted and 
delayed by 20 ns. 

The Futurebus+ AS* input inverted and 
delayed by 30 ns. 

The Futurebus+ DS* input inverted. 
Data acKnowledge (inverted) output to 
the Futurebus+ DK* signal from the 
S_GAL1. 


A feedback signal from the Memory 


Module Controller indicating that an AC- 
cess is still in Progress S__GAL2 will not 
end the current memory access 
(AREQ~) or allow AK* to be released 
until ACIP ~~ is deasserted. 


7.4 S__GAL2 Outputs 

CS_AS ~ . Indicates that a Chip-Selected Address 
Synchronization access request has 
been received from Futurebus+ when 
asserted. 


Access REQuest input used to produce 
AREQ ~. This output when asserted im- 


plies that a chip-selected request from 
Futurebus+ has been received and 
clocked by the local clock. 


The Access REQuest input to the mem- 
ory module. This output when asserted 
implies that a chip-selected request 
from Futurebus+ has been received 
and clocked through two rising edges of 
the local 25 MHz clock. This synchroniz- 
es the request from Futurebus+ to the 
local clock. This output is used as an in- 
put to the memory module to request a 
DRAM access. 


A signal indicating the initial Futurebus + 
access when asserted. This input is 
deasserted during the first access. 


Address acKnowledge (inverted) output 
to the Futurebus+ AK* signal. 


The Latch Enable for Input Address and 
Command bits from Futurebus +. This is 
an input to the 74F373 latches and al- 
lows the address or command from the 
Futurebus+ to be enabled (when as- 
serted) or latched (deasserted). Note 
that this latch follows the Futurebus + 
DS3886 latches and holds the address 
and command latched until the com- 
plete transaction is terminated (AS* re- 
leased). 


F_INITACC ~ 


AK 


LEI_ADD_.CM 
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The direction input to the DS3886 
Futurebus+ latched data transceivers. 
When asserted address or data is re- 
ceived into the slave memory board. 
When deasserted data is transmitted to 
the Futurebus+ backplane. 


The Latch Enable for Input Status (and 
Capability bits if desired) from Future- 
bus+. This is an input to the 74F373 
Jatches and allows the status and capa- 
bility bits from the Futurebus+ to be en- 
abled (when asserted) or latched (deas- 
serted). Note that this latch follows the 
Futurebus+ DS3886 latches and holds 
the status and capability latched until 
the complete transaction is terminated 
(AS* released). This output is very simi- 
lar to LEI_ADD__CM but does not latch 
until the filtered version of Al* is re- 
ceived. 


PART 2. DESCRIPTION OF MEMORY MODULE 
DESIGN 


8.0 GENERAL DESCRIPTION 


This application note describes a Futurebus+ like Memory 
Module that can support burst transfer rates of 20 mega- 
transfers/second. This Memory Module utilizes two 
DP8422A-25 DRAM controllers (8420_.MODULEO and 1), a 
GAL interface module consisting of 5 PALs, (MEM__MOD- 
ULE__CTR), and latched transceivers (i.e., 74F543’s). 


This design could form the basis of a Futurebus+ slave- 
only DRAM memory board (Figure 1, 2, 22), or it could be 
used in an I/O board design. An I/O board can act as botha 
master and a slave with respect to the Futurebus+. Figure 
36 shows one possible I/O board design containing DRAM 
memory, a CPU, and an I/O controller. In Figure 36 the I/O 
controller is the National Semiconductor DP83932 Systems- 
Oriented Network Interface Controller (SONIC). 


All DRAM access requests are assumed to be handled by 
an on-board arbiter in the case where the board contains 
processors along with the Futurebus+ interface and DRAM 
memory. The dual access control logic of the DP8422A-25 
is not used in this design. This is because an external arbiter 
is needed to control the local busses, and this same logic 
can control accesses to the DRAM as well. Many proces- 
sors have built-in support for local bus arbitration, such as 
the 68030, which includes three signals to perform this task 
(i.e., Bus Request, Bus Grant, and Bus Grant ACKnowl- 
edge). The protocol controller could have a similar type of 
arbitration structure. When one of the devices is granted 
control of the local bus, the other devices TRI-STATE® their 
address, data, and control busses. The control signals nec- 
essary to interface this memory design to the Futurebus+ 
protocol controller and on-board CPU are described in Sec- 
tion 14. 

Figure 36 shows a block diagram of a portion of a Future- 
bus+ 1/O card that includes DRAM, the SONIC, and a local 
CPU. The SONIC, CPU, and the Futurebus+ protocol con- 
troller share the local data bus, address bus, and control 
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bus. The local data bus is buffered from the DRAM and 
separately buffered from the asynchronous Futurebus+ 
data bus. This was done to simplify the control logic, though 
it should be possible to use only one set of buffers for both 
the Futurebus+ and the local data bus. 


This memory design supports intervention. Intervention al- 
lows the system memory to operate in a multiprocessing 
cache-based environment. In intervention a read access 
from DRAM may be changed to a write access if another 
Futurebus+ cache boards owns (has modified) that particu- 
lar piece of data but not yet updated the system memory. 
During intervention the true data is passed to the system 
from the owner, and the system DRAM is updated with the 


correct value. In other words, a DRAM read transaction may 
become a write transaction after the address has been is- 
sued. To allow this feature the DRAM design has the restric- 
tion that the initial DT__STB’ must not be generated until it 
is known whether the current transaction involves interven- 
tion. In other words, the ‘READ’ input to the DRAM interface 
must be valid before the intial ‘DT__STB’ edge is given to 
the DRAM interface. 


Another restriction in the DRAM interface is that the access 
request (AREQ ~ ) input should be synchronized to the input 
clock.‘CLK’. Also the initial ‘DT__STB’ should not be gener- 
ated until the DRAM interface outputs address acknowl- 
edge, ‘ADD_ACK’. 


Control for Bank 1 
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Control 


CONTROL | anpress 
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Parity Generation 
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FIGURE 22. Meriory Module Block Diagram 
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9.0 DRAM CONTROLLER DESCRIPTION 
(8420_.MODULEO, 1) 


Two DP8422A-25 DRAM controllers were utilized in this de- 
sign. This allows one DRAM controller per bank of DRAM. 
The Memory Module was designed this way for the follow- 
ing reasons: 


1. The control logic could be simplified since the two memo- 
ry banks can be controlled completely independently; 


2. Greater performance because of interleaved memory 
banks; 


3. Greater performance because of less capacitance on the 
output drivers; and, 


4. Increased drive capability (up to two banks of 64 bits per 
bank) without a loss in performance. 


This memory design takes care of: 
1. All DRAM timing; - 
2. Arbitration between refresh and access cycles; 


3. The automatic insertion of wait states to the accessing 
device when needed (i.e., RAS~ precharge, refreshing); 


4. Byte reads and writes to 32-bit (or 64-bit) memories; 
5. Normal and burst operations, and; 


6. Incrementing the column address of each bank during 
burst accessing. 
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Only port A of the DRAM controllers is used in this design, 
port B is disabled by tying ‘AREQB ~’ high. In other words, 
the dual access arbitration circuitry of the DP8422A-25’s 
was not used in this design. All arbitration between different 
devices trying to access the DRAM, as well as DRAM re- 
fresh, is controlled external to the DP8422A-25's, 


10.0 GAL INTERFACE MODULE DESCRIPTION 
(MEM_.MODULE_CTR) 

There are 5 PALs (GALs were used in the computer simula- 
tion) used-in this design to interface between the DRAM 
controllers, the 74F543 transceivers, and the Futurebus+ 
protocol controller. Section 14 describes the inputs and out- 
puts of the GAL interface, while Section 15 shows the GAL 
equations that were programmed into the GALs. 

Figures 22, 23, 24, 25, 26 are shown to give a graphical 
representation of the GAL design logic of the Memory Mod- 
ule through block diagrams and state transition and decoder 
diagrams. ° : : 
Figures 27 through 33 show actual simulation timing dia- 
grams of the Memory Module design through various read, 
write and DRAM refresh operations. 
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FIGURE 23, Futurebus+ Memory System Asynchronous Controller Block Diagram (MEM_.MODULE_CTR) 


READ ACCESSES 


ICSGAREQ~ & 
DT_STB stable 


DT_STB edge 
& 1B1 & !ENOD~ 


ICSGAREQ~ & 
INITODD~ & 
DT_STB stable 


(DT_STB edge & ! ENEV~ ) 


+ (1B1 & !INITACC~) 


(B1 & IINITODD~) 

+ (DT_STB 

edge & ! ENOD~) 
ICSGAREQ~ 
& OT_STB 
stable 


| . \CSGAREQ~ en DATA STATE ey 


ICSGAREQ~ & 
INITACC~ & 
DT_STB stable 


TL/L/10772-5 


FIGURE 24. Futurebus+ Memory System State Transition Diagram 
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FIGURE 30. Memory Module Write Access (Even Address) 
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FIGURE 31. Memory Module Read Access (Odd Address) 
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FIGURE 32. Memory Module Write Access (Odd Address) 
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FIGURE 33. Memory Module Refresh then Read Access (Odd Address) 
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A potential DRAM access is initiated by CS~ and AREQ~ 
(Chip Select and Access REQuest) being driven low. Once 
the RAS~s are low and the DRAM column address is valid 
at the DRAM inputs the GAL Interface Module drives the 
ADDress phase ACKnowledge (ADD__ACK~) low to the 
Memory Module controller. Seeing ADD_ACK~ the Mem- 
ory Module Controller can now request a DRAM read or 
write access through the Futurebus+ DaTa STroBe 
(DT__STB edge). During the initial access of a read or write 
operation the first DT_STB edge will always be a rising 
edge. 

This Memory Mcdule design assumes two banks of memo- 
ry. These two banks of Memory (DRAM) are an even ad- 
dress bank (bank 0) and an odd address bank (bank 1) 
controlled by the least significant double word address bit 
(B1): The Memory Module will determine whether the ac- 
cess is an even address (bank 0) access or an odd address 
(bank 1) access by looking at the lower address bank eos 
input (B1). 

Each DRAM access is initiated through an DT__STB edge 
from the Memory Module Controller. When the GAL Inter- 
face Module sees this edge an access to the even address 
bank O or the odd address bank 1 takes place. The 
MEM__GAL2 produces’ . the state variables 
(EVEND~ and ODDD~) from the DT__STB edge that 
cause each DRAM access to take place. These state 
variables are inputs to delay lines (EVENDEL, ODDDEL, 
see Figure 7) that produce delayed versions of the initial 
state variable input. The delayed versions of these inputs 
(E10-80~ and 010-80 ~) are used as inputs to the other 
four GALs in this Interface to produce the outputs that 
control the entire operation of the Memory Module Inter- 
face (see Figures 3, 6, and 7). 

The first access request (DT_STB edge) of any read oper- 
ation causes two accesses (see Figure 27). The first ac- 
cess retrieves and latches the data needed for the present 
access. The second access outputs the needed data onto 
the Futurebus+ asynchronous data bus, drives the data ac- 
knowledge output (D__ACK) for the current access, and 
performs a DRAM access to get the next sequential piece 
of data for the next access request (DT__STB edge). In oth- 
er words, read operations are pipelined. The data needed 
for the current access (DT_.STB edge) was accessed and 
latched into the output transceivers during the previous ac- 
cess. 


Each subsequent read access, during a burst read opera- 
tion, performs only one memory access operation. As an 
example see Figure 29 and refer to the DT__STB edge for 
the data ‘D4’. This rising edge of DT__STB has a ‘4’ to the 
left of the rising edge. In this timing diagram the current 
access request (DT__STB edge) isa read access from an 
even address (bank 0). The currently needed even address 
data was accessed and latched in the preceeding odd ad- 
dress read access (see the ‘BOCAS~’ signal labeled ‘4’ 
and the ‘RLEO~’ signal labeled ‘Latch 2’). An enable signal 
is generated during the current access to drive the data, D4, 
onto the Futurebus+ asynchronous data bus (see the 
‘EN_F__DO ~’ signal labeled ‘Enable 4’ on the timing dia- 
gram). The data for the next sequential transfer request 
(from bank 1) is accessed and latched during the current 
access (see ‘B1CAS’ signal labeled ‘5’ and the ‘RLE1’ sig- 
nal labeled ‘Latch 5’). Therefore, the present read access 
outputs even address bank O data and performs a DRAM 
access and latching of the odd address bank 1 data in prep- 
aration for a subsequent odd address read access. 
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During a Memory Module read access, each piece of data 
accessed from the DRAM is guaranteed a setup time on the 
Futurebus+ asynchronous data I/O bus (see Figure 22) 
with respect to the Futurebus+ data ACKnowledge 
(D_ACK), and is held valid until the next access is request- 
or the access 


ed (DT_STB edge), is terminated 
(CSGAREQ~ high). 

During write accesses, the data to be written to the Memory 
Module is latched into the write transceiver latches, and 
then an D_ACK signal is output to allow the next piece of 
write data to be enabled onto the Futurebus+ asynchro- 


nous data I/O bus. 


In controlling the DP8422A-25’s, the GAL Interface Module 
must increment the column address of the DRAMs after 
each access via the COLumn INCrement (COLINCO and 1) 
input, one for each DRAM bank. 


This interface guarantees a column address setup and hold 
time for the present access (see Section 4.7 and 4.9) and 
then increments the column address to prepare for the next 
access through the DP8422A-25 COLINC inputs. 


During an initial odd address read access, COLINCO is 
pulsed before the first even address bank 0 access is per- 
formed: to guarantee that the even access is to the next 
sequential double word of data (see Figures 25 and 37). 


It should be noted that this Memory Module does not in- 
clude logic to sense when the DRAM accesses cross a 
DRAM page boundary. It is assumed that the master that is 
reading or writing the Memory Module contains the required 
logic to stop accessing the DRAM before crossing a DRAM 
page boundary. 


The MEM__GAL1 controls the enable signals to the read 
access transceivers (EN_F_.DO~, EN__F__D1~), the 
latch enable signals during write transactions (WLEO~, 
1~), the write enable signal to the DRAMs (WE ~), and the 
Futurebus+ data ACKnowledge (D__ACK) output to the 
Memory Module controller. 


The MEM_GALS3 controls the random logic needed i in the 
Memory Module interface, including; ADDress ACKnowl- 
edge (ADD_ACK ~) to the Memory Module controller, the 
ReFreSH input to the DRAM controllers (RFSH ~ ), the Chip 
Selected and Granted Access REQuest (CSGAREQ ~ ) sig- 
nal, and the latched versions of the E80~ and O80~ out- 
puts of the delay lines (LE80~ and LO80~). 


MEM__GAL4 and MEM_.GAL5 control the byte CAS ~ s for 
each bank (CAS ~ 0-3), the Read access Latch Enable for 
the individual bank (RLEO~ or RLE1~), and the COLumn 
INCrement signal for the individual bank ma or 
COLINC1). 


11.0 LATCHED TRANSCEIVER DESCRIPTION 
(MEM_MODULE_CTR) 


The 74F543 latched transceivers are “iebdea to gain the 
necessary performance by performing pipelining of the data. 
For example, in an even bank 0 read access, the even piece 
of data (from the bank 0 transceiver latch) is enabled onto 
the Futurebus+ asynchronous data bus while the next se- 
quential piece of data from the odd bank 1 is accessed and 
latched into the bank 1 transceiver latch. During a write ac- 
cess, an acknowledge (D__ACK) can be generated after the 
data is latched into the write transceiver latch. The actual 
writing of the data into the DRAM occurs simultaneously 
with D_ACK. 
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12.0 FUTUREBUS~+ MEMORY MODULE 
DP8422A PROGRAMMING BITS 


Programming 
Bits Description 


ECASO~ = 1 Extend CAS~ and Get Refresh Request 
(RFRQ~) Output Instead of WE~. 


B1=1 ’ Access Mode 1 
BO =0 ADS~ Low Latches the Address 


cg = 1 Delay CAS~ during Write Accesses by 
One Clock 


Row Address Hold Time of 15 ns Minimum 


Column Address Setup Time of 0 ns Mini- 
mum 

RAS ~ 0-3 and CAS~ 0-3 are all Select- 
ed during an Access 

BO and 1 are Not Used during an Access 


15 ys Refresh Period 


Assuming a 20 MHz DELCLK Input, a Delay 
Line Clock Divisor of 10 was Selected 


RAS ~ 0-3 All Low Simultaneously during 
Refreshing 


Non-Address Pipelined Mode 


Data Transfer ACKnowledge (DTACK~) 
Output Selected 


WAITIN~ Low Adds One Clock Delay to 


DTACK~ 
DTACK~ Will Remain (iow during Burst 

' Accesses 
DTACK ~ Will be Asserted on the First Ris- 
ing Clock Edge 
After the Access RAS~ Transitions Low 
RAS ~. Low during Refresh for 4 Clock Pe- 
riods and 3 Clock Periods of RAS~ Pre- 


charge between Any Two Access to the 
Same Bank 


13.0 TIMING CALCULATIONS 
1. The Minimum time from Access REQuest (AREQ~) to 
the initial DaTa STroBe (DT__STB) is: 
100 ns (ADD_ACK~ gets generated on the second 
clock after AREQ~ transitions low) 
—10 ns (assume 10 ns maximum delay of Clock to 
AREQ~ generated) 
. +10 ns (GAL16V8-10 max delay of ADD_ACK~ of 
MEM__GALS3) 
= 100 ns, Therefore from AREQ~ to the initial 
DT_STB is 100 ns minimum since DT__STB must not 
transition untii ADD_ACK ~ is generated. 
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2. Initial Read access even (or odd) address DT_STB to 


D_ACK: 


’ 10 ns (GAL20V8-10 max delay of DT_STB to ODDD~ 


of MEM__GAL2) 


’ +32 ns (max delay time of 30 ns tap of delay line) 


+10 ns (GAL20V8-10 max delay of ENEV~ of 
MEM__GAL2) 


+10 ns (GAL20V8-10 max delay of EVEND~ of 
MEM._GAL2) 


+22 ns (max delay time of 20 ns tap of delay line) 


+10 ns (GAL22V10-10 max delay of D_ACK of 
MEM_GAL1) 


= 94 ns maximum 
Substituting into the above equation typical values (7 ns 


_ + 30ns + 7ns + 7ns + 20ns + 7 ns) gives a typical 


time of 78 ns. 


. All Write accesses and none-initial Read accesses 


DT__STB to D_.ACK: 

10 ns (GAL20V8-10 max delay of ENEV~ or ENOD~ of 
MEM__GAL2 from previous access) 

+10 ns (GAL20V8-10 max delay of DT__STB to EV- 
END~ or ODDD~ of MEM_GAL2) 

+22 ns (max delay time of 20 ns tap of delay line) 

+10 ns (GAL22V10-10 max delay D_ACK of 
MEM__GAL1) 

= 52ns 

Substituting into the above equation typical values (7 ns 


+ 7ns + 20 ns + 7 ns) gives a typical access time of 
41 ns. 


. Worst case and typical minimum time between D_ACK 


to the next D_ACK is: 
52 ns (Worst Case, see #3 above) + Xns, 


41 ns (Typical Case, see #3 above) + Xns. Where ‘x’ is 
the time from D_ACK to the next DT__STB. 


. Worst case and typical minimum time between D_ACK 


to the next D__ACK to the same memory bank (Even 

address access to the next Even address access, or Odd 

to Odd address access): 

10 ns (GAL20V8-10 max delay of DT_.STB to EVEND~ 
or ODDD~ of MEM__GAL2) 


+84 ns (max delay time of 80 ns tap of delay line) 


+10 ns (GAL20V8-10 max delay of LE80~ of 
MEM__GAL3) 


+10 ns (GAL20V8-10 max delay of ENEV~ of 
_. MEM_GAL2) 

= 114 ns Worst Case Minimum 

The typical minimum time would be (7 ns + 80 ns + 7 

ns + 7 ns) 101 /ns. This is where the 20 Mega-transfers 

per second transfer rate comes from (two transfers in 

100 ns is 20 Mega-transfers per second). 


Here the minimum time for enabling EVEND~ after the 
previous EVEND~ was enabled was calculated to be 
the same as Even address D_ACK from the previous 
Even address D_ACK. 


. Worst case Data Setup time to D_ACK during Read ac- 
‘cess cycles (assume that 74F543 Octal Registered 


Transceivers are used): 





3 ns (GAL20V8-10 min delay of DT_STB to EVEND~ 
or ODDD~ ‘of MEM__GAL2) 

+18 ns (minimum delay of 20 ns tap of delay line, start- 
ing from EVEND~ or ODDD~ of MEM__GAL2) 

+8 ns (D_ACK delay of MEM_ACCESS) 

— 10 ns (worst case delay of DT__STB to EN_F_DO~ 
or EN_F__D1~ of MEM__GAL4; 2 ns worst case 
difference between EN_F_DO~, 1~ and 

. D_LACK delays, since they are in the same GAL 
and their delays will tend to track each other) 
_—12 ns (74F543 max delay of OEBA~ or OEAB~ to 
output valid) 
= 7ns 


9. Worst case Column Address Hold time from CAS~ low 


(80 ns DRAMs require 20 ns), calculated from EVEND ~ 

or ODDD~: 

28 ns (min delay of 30 ns tap of delay line) 

+8 ns (GAL20V8-10 delay of COLINC of 
MEM__GAL4, 5) 

+3 ns (assumed min delay of DP8422A-25 COLINC to 
‘Q’ address outputs starting to change) 

—10 ns (GAL20V8-10 max delay of CAS~ low of 
MEM__GAL4, 5, this gives a 2 ns worst case differ- 
ence between COLINC and CAS~ since they are in 
the same GAL) 


= 29ns 
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. COLINC setup time to the DRAM CAS~ low (the 
DP8422A-25 dictates that 39 ns minimum is necessary 
to guarantee a column address setup time of 0 ns, see 
parameter #27 in DP8422A-25 data sheet. We will cal- 


14.0 GAL INPUT AND OUTPUT DEFINITION 


14.1 Definition of Memory Module State Variables 
EVEND~ This output is driven low during an access to 


culate this value starting from the 30 ns tap of the delay 

line that asserts COLINC): 

-10 ns (GAL20V8-10 max delay of COLINC of 
MEM__GAL4, 5) 

+47 ns (minimum delay from 30 ns tap to 80 ns tap of 
delay line) 

+3 ns (GAL16V8-10 minimum delay of LE80~ of 
MEM ~ GAL3) 

+3 ns (GAL20V8-10 minimum delay of ENEV~ of 
MEM__GAL2) 

+3 ns (GAL20V8-10 minimum delay of EVEND~ of 

" MEM_GAL2) 

+8 ns (GAL20V8-10 delay of CAS~ or MEM_GAL4, 5; 
this gives a 2 ns worst case difference between 


COLING and CAS~ delays, since they are in the 
same GAL) = 54 ns. 


’ This value translates into 54 ns-39 ns (COLINC to col- 
umn address valid on DP8422A-25 outputs) = 15 ns. 
Therefore the worst case column address setup time to 
CAS ~ low is 15 ns. 

. Worst case data setup time to D_ACK during Read Ac- 

cess Cycles, calculated from CAS~ low to data valid, 

assuming 80 ns DRAMs. The DRAM access time can be 

’ calculated as follows; #7 above calculated 15 ns column 
address setup time to CAS~ low. Since the column ad- 
dress access time of an 80 ns DRAM is 40 ns, this gives 
40 — 15 = 25 ns real worst case DRAM access time. 
Since the CAS~ access time of an 80 ns DRAM is 
20 ns, the 25 ns value calculated above is used as the 
real CAS ~ low to data valid access time of the DRAM.: 
—10 ns (GAL20V8-10 max delay of EVEND~ or 

_ _ODDD~ to CAS~ low of MEM_GAL4, 5) . 

—25 ns (CAS~ low to data valid of the DRAMs) 

—12 ns (74F543 max delay of enable to data valid) 

+ 28 ns (min delay of 30 ns tap of delay line) 

+3 ns (GAL20V8-10 min delay of ENOD~ or ENEV~ 
of MEM_GAL2) © 

+3 ns (GAL20V8-10 min delay of ODDD~ or EVEND~ 
of MEM_.GAL2) 

+18 ns (min delay of 20 ns tap of delay line) 

+3 ns (GAL20V8-10 min delay of D_ACK of 
MEM__GAL1) 

= 8 ns worst case data setup. 
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the even address bank as indicated by either 
a rising or falling edge of ‘DT__STB’ (depend- 
ing upon whether the initial access was an 
even or odd bank access as indicated by 
‘B1’). This output drives the Even Delay Line 
(EVENDEL) whose outputs drive the other 
PALs that control the operation of the Memo- 
ry Module. 


This output is driven low during an access to 
the odd address bank as indicated by either a 
rising or falling edge of ‘DT_.STB (depending 
upon whether the initial access was an even 
or odd bank access as indicated by ‘B1’). 
This output drives the Odd Delay Line 
(ODDDEL) whose outputs drive the other 
PALs that contro! the operation of the 
Memory Module. 


14.2 Definition of Memory Module Control Inputs 
CLK 


The Memory Module system CLocK (20 MHz 
was used in this design, though any frequen- 
cy could be used up to 25 MHz). This clock 
drives the DP8422A-25 and synchronizes the 
RFSH~ and ADD_.ACK~ outputs. It also 
synchronizes the AREQ~ input to the 
DP8422A-25. 


This input, Access REQuest, starts a Memory 
Module access along with Chip Select 
(CS~). 

The Chip Select input selects an access to 
the Memory Module when low. 


An active high signal indicating a READ ac- 
cess from the DRAM when asserted. 


The least significant double-word (32 bits) or 
quad-word (64 bits) address bit, depending 
upon whether the Memory Module is 32 bits 
or 64 bits wide. During an access where the 
initial access is an even address from the 
even address bank (Bank 0), B1 will equal 0. 
During an access where the initial access is 
an odd address from the odd address bank 
(Bank 1), B1 will equal 1. 
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A latched and inverted version of the WRite 
command (WR"*) from Futurebus+. This 
command indicates that a write access is in 
progress when asserted and is held latched 
until AS* is released. 


A inverted version of the InterVention (IV*) 
status bit from Futurebus +. When this bit is 


"asserted during a read access it indicates 


that another module is intervening in the 
current access and providing the data. The 


slave memory module will perform a write 


access, in order to update the memory with 


the correct data, instead of performing the 
requested read access. See Section 4 for 
more information. 


This is the DaTa STroBe and must be gen- 


‘erated from the module that interfaces to 


. this Memory Module. This signal is edge 


sensitive. In other words, each rising or fall- 
ing edge occurring after AREQ~ and 
ADD__ACK~ are low and before AREQ~ 


_transitions high means that the Control 


Module requires that data be either read or 
written from/to the DRAM array. The initial 
transition on this input will always be a rising 
edge, and the B1 input defines whether this 
edge is an even or odd address access. 


This is the ReFresh ReQuest output of the 
Bank 0 DP8422A-25 DRAM controller. This 
output signals that a refresh of the DRAM 
should be performed as soon as is conve- 
nient, but within the next 15 ps. 


: This is the ReFresh In Progress output of 


BO__DTACK ~ 


G_F_BUS ~ 


CPU_WE ~ 


the Bank 0:DRAM controller. This output 
signals that a DRAM refresh is currently in 
progress. 

This is the DaTa ACKnowledge output of 
the Bank 0 DRAM controller. This output 
signals that the requested DRAM access is 
currently in progress. This output will not go 
low until RAS~ goes low for the current ac- 
cess guaranteeing that the previous access 
and all RAS~ precharge requirements from 
the present access have been met. See the 


‘ DP8422A-25 data sheet for more details. 


This is the Grant FutureBUS signa! from an 
external arbiter. This signal would be need- 
ed in a board design where several different 
types of devices would be accessing the 
Memory Module. When this signal is low, it 
signifies that the high speed memory design 
protocol explained in this application note 
currently has contro! of the DRAM. When 
high, a normal CPU access can take place 
over a local bus with its own separate trans- 
ceivers and control logic. 


A Write Enable signal from a local on-board 
CPU, if one exists. 
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BE ~ (3:0) 


Byte enable signals for a 32-bit wide Memory 
Module that is assumed by this design. These 
inputs are needed to control the byte CAS ~ 
inputs to the DRAM array. For a 64-bit wide 
Memory Module the interface would have to 
be redesigned slightly to accommodate 8 
Byte Enable signals. 


’ A CAS~ enable signal for a local on-board 


BOCASO ~ 


BiCASO~ 


CPU to control along with the BE ~ (3:0) sig- 
nals. This input allows an on-board CPU to 
control the byte CAS~s to the DRAMs. 

The Bank 0 DRAM controller BOCAS ~ 0 out- 
put. 

The Bank 1 DRAM ROnUOHEr BiCAS~ a out- 
put. 


14.3 Definition of Memory Module Control Outputs 
BO_.CAS ~ (3:0) These are the Bank 0 Byte CAS~ out- 


puts that drive the Bank 0 DRAM array. 


Bt _cAs~ ams 0) These are the Bank 1 Byte CAS~ out- 


CSGAREQ~ 
RFSH~ 


COLINCO 


COLINIC1 


WE~ 


puts that drive the Bank 1. DRAM array. 


This signal indicates a Chip Selected and 
. _ arbitration Granted Access REQuest to 
the DRAM array. 


This output to the DRAM controller caus- 
es a DRAM ReFreSH cycle to occur as 
soon as possible. 


This is the COLumn INCrement (COLINC) 
input to the Bank 0 DRAM controller. 


This is the COLumn INCrement (COLINC) 
input to the Bank 1 DRAM contoller. 


This is the Write Enable, as to the 
DRAM array. 


This is the Data ACKnowledge output re- 
sponse to the DT__STB access input re- 
quest. A rising or falling edge of this signal 
signifies that the desired read or write ac- 
cess that was requested earlier by 
DT_STB has been completed and a 
new access request, via the OT. __STB 
input, may be initiated. 


A signal from the Memory Module Con- 
troller indicating that an ACcess is still in 
- Progress. The FB_ADD GAL will not end 
the current memory access (AREQ~ ) or 
- allow AK*. to be released until ACIP~ is 
deasserted. 


14.4 Definition of Other Signals in the Design 


ROW(10:0)' 


COL(10:0) 


B(1:0) 


ROW Address to the DRAM Controller. 


COLumn Address to the ORAM Control- 
ler. 


Bank Address to the DRAM controller. In 
this design the bank inputs do: not. cause 
any change in the function.of the DRAM 
controller, since the DP8422A-25 has 
been programmed in the all RAS~ low 
during an access mode. However, the 
“B1” input is used to signal whether the 
initial access is to the even address bank 
O or the odd address bank 1. 








WAITIN~ 


DISRFSH ~ 


ML~ 


DIBO(7:0) 
DIB1(7:0) 
DOBO(7:0) 


DOB1(7:0) 


Allows wait states to be added to an access 
(see DRAM controller data sheet). 


Controls whether internal automatic refresh- 
es or externally controlled refreshes are en- 
abled (see the DRAM controller data sheet). 


Used to program the DRAM controller (see 
the DRAM controller data sheet). 


These are the data inputs to the bank 0 
DRAMs. This simulation only looked at 8 
bits, but in a normal design, each bank of 
DRAM would contain 32 or 64 data bits. 


These are the data inputs to the bank 1 
DRAMs. This simulation only looked at 8 
bits, but in a normal design, each bank of 
DRAM would contain 32 or 64 data bits. 


These are the data outputs of the bank 0 
DRAMs. This simulation only looked at 8 
bits, but in a normal design, each bank of 
DRAM would contain 32 or 64 data bits. 


- These are the data outputs of the bank 1 


DRAMs. This simulation only looked at 8 
bits, but in a normal design, each bank of 
DRAM would contain 32 or 64 data bits. 


This is the |/O data bus on the other side of 


. the Memory Module transceivers. This simu- 
lation only looked at 8 bits, whereas a nor- ° 
‘mal design might contain 32 or 64 bits.’ 


14, 5 Other Signals from MEM__ GAL2 | 


ENOD~ 
ENEV~ 
INITACC~ 


F_DO~ 


F_DE~ 


INITODD ~ 


ENable an ODd address access to occur. 


ENable an EVen address access to occur. 
The INITial ACCess (first access) is in Plog: 


ress, 


A delayed version of DT. _STB during an 


odd address access: 


A delayed version of DT_STB during an 
even address access. 


Indicates that the initial access is an odd 
address access. This is useful during read 
accesses, because during the ‘initial odd 
bank access, COLINCO must be asserted 
so thatthe next even address access is to 
the next sequential word. ° 
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14.6 Other Signals from MEM_GAL3 


LE80~ 


ADD_ACK ~ 


A latched version of E80 ~ low. This output 
stores the E80 ~ low transition, and is reset 
by E30~ transitioning low. 


A latched version of O80 ~ low. This output 
stores the O80~ low transition, and is re- 
set by O30~ transitioning low. 


This output signals that the address phase 
of a DRAM access is complete, ADDress 
phase ACKnowledge. This output is syn- 
chronized to the system clock (CLK), and 
indicates that data can now be read or writ- 
ten to the DRAM array (DT_STB can now 
transition). 


14.7 Other Signals from MEM_GAL1 


READ 


An active high signal indicating a READ ac- 
cess from the DRAM when asserted. This 
output is derived from the latched WR* 
command bit from Futurebus+ and held 
latched in this GAL until the DRAM access 
is completed as indicated by CSOGAREQ~ 
being deasserted. 


This output enables the transceiver to out- 
put data from the Bank 0 DRAM array, 
DOB0(7:0), to the data !/O bus, D(7:0). 
This output enables the transceiver to out- 
put data from the Bank 1 DRAM array, 
DOB1(7:0), to the data I/O bus, D(7:0). 
This output latches the data from ‘D(7:0)’ 
into the transceiver to write to the Bank 0 
DRAM, DIBO(7:0) when high. 

This output latches the data from ‘D(7:0)’ 
into the transceiver to write to the Bank 1 
DRAM, DIB1(7:0) when high. 


14.8 Other Signals from CAS__GAL1 and CAS_GALO | 


RLEO~ 


This output latches the data out of Bank 0 of 
the DRAM, DOBO0(7:0), into the transceiver 
to be output to the data I/O bus, D(7: °) 
when high. 

This output latches the data out of Bank 1 of 
the DRAM, DOB1(7:0), into the transceiver 
to be output to the data !/O bus, D(7: 
when high. 

This output enables the daa to be written 
into the DRAM (D(7:0)) through the 74F543 
transceivers when low. 
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15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN 


MODULE 
TITLE 


S.GAL1 


S_GAL1.ABL 
RUSTY MEIER 02.22.90! 


S.GAL1L device ‘'P22V10'; 
CS_AS~ pin 1; 

WR pin 2; 

Iv pin 3; 
ADD_ACK~ pin 4; 
ADD_ACK_10~ pin 5; 

D_ACK pin 63 
D_ACK_10 pin 73 

DK_IN pin 8; 

DI_IN pin 9; 

AS_30 pin 10; 
AS_40 pin 11; 

GND pin 12; 
EQUATIONS 

'AT = (AS_30 & AS_40) ; 


DT_SIB (!1CS_AS~ & IWR & 


pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
F.. INITACC~ pin 


{IV & DS & !FLINITACC~ & 


\ADD_ACK~ ) 
(!CS_AS~ & !WR& !IV & !ADD_ACK~ & !DS & 
ID_ACK & F_INITACC~) 
WR& Ve IDS e 


(DT_STB & !CS_AS~ & 


(DT_STB & !CS_AS~ & !WR & SIV & !D_LACK & 
' ADD_ACK~ ) 
(!CS_AS~ & WR & SIV & 
& DS & DS_10 & !D_ACK.10) 
ICS_AS~ & WR & !IV & !ADD_ACK~ & 
FLINITACC~ & !D_ACK_10) 
ICS_AS~ & WR & SIV & !ADD_ACK~ & 
F.INITACC~. & DS_10) 
SADD_ACK~ & FLINITACC~ & DS 
& DK_IN & DKI_10 & !D_ACK.10) 
ICS_AS~ & IV & !ADD_ACK~ & 
F_LINITACC~ & !DI_IN) 
ICS_AS~ & IV & !ADD.ACK~ & 
FLINITACC~ & !DII_10) 
ICS_AS~ & IV & !ADD_ACK~ & 
FLINITACC~ & !D_ACK_10) 
1CS_AS~ & IV & !ADD_ACK~ & 


FLINITACC~ & DS & DK); 


(DT_STB & 
(DI_STB & 
(I1CS_AS~ & IV & 
(DT_STB & 
(DT_STB & 
(DIT_STB & 


(DT_STB & 


!ADD_ACK~ ) ~ 


{ADD_.ACK~ & FLINITACC~ 


'S_GAL1, THIS IS THE FUTUREBUS+ DATA PHASE CONTROLLER GAL. 


BRING AI VALID ONCE THE ADDRESS STATUS IS VALID 


REQUEST -READ= MEMORY ACCESS DURING THE 
INITIAL F_BUS REQUEST ONCE THE DRAM 
ADDRESS ACKNOWLEDGE IS RECEIVED 

REQUEST READ MEMORY ACCESS DURING 
SUBSEQUENT F_BUS DS READ REQUESTS 

HOLD DT_STB HIGH WHILE DS IS LOW 


HOLD DT_STB HIGH UNTIL D.ACK CHANGES 
REQUEST ~-WRITE- MEMORY ACCESS DURING A 
F.BUS DS WRITE REQUEST 
HOLD DT_STB HIGH WHILE D.ACK IS Low 
HOLD DT_STB HIGH UNTIL DS HAS BEEN 
LOW AND D_ACK HIGH FOR 10NS 
REQUEST ~ INTERVENTION— MEMORY ACCESS 
HOLD DILSTB HIGH ‘DURING INTERVENTION 
HOLD DT_STB HIGH DURING INTERVENTION 


HOLD DI_STB HIGH DURING INTERVENTION 


HOLD DI_STB HIGH DURING INTERVENTION 
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15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


LEILA_D = (!AS_30) * LET ADDRESS FALL-THRU 
# (ICS_AS~ {Iv & !ADDLACK~ & WR & DS & *" FALL-THRU LATCHES DURING ODD BEAT WRITES 
'IDACK & !DS_10) 
# (!CS_AS~ {IV & !ADDLACK~ & WR & DS & FALL-THRU DURING ODD BEAT WRITE ACCESSES 
ID.ACK & D.ACK_10) 
# (!CS_AS~ {IV & !ADD_ACK~ & WR & DS & FALL-THRU DURING ODD BEAT WRITE ACCESSES 
!D.ACK & ADD_ACK_10~ ) 
# (!CS_AS~ !ADDLACK~ & WR & !IV & IDS & FALL-THRU DURING EVEN BEAT WRITES 
DS_10 & D_ACK) 
# (!CS_AS~ 'TADD_ACK~ & WR & SIV & IDS & FALL-THRU DURING EVEN BEAT WRITES 
D_ACK & !D_ACK_10) 
# (!CS_AS~ !ADD_ACK~ & IV & DK_IN & DS & FALL-THRU DURING ODD BEAT INTERVENTION 
'DKI_10 & !D_ACK) 
# (!CS_AS~ !ADD_ACK~ & IV & DK_IN & DS & FALL-THRU DURING ODD BEAT INTERVENTION 
# 
# 
# 


!DLACK & DLACK_10) 

(!CS_AS~ 'ADD.ACK~ & IV & DKLIN & DS & FALL-THRU DURING ODD BEAT INTERVENTION 
{D.ACK & ADD_ACK_.10~) 

(!CS_AS~ !ADD_ACK~ & IV & DI_IN & !DS & FALL-THRU DURING EVEN BEAT INTERVENTION 


: !DII_10 & D_ACK) : 
(!CS_AS~ & !ADD.ACK~ & IV & DI_IN & !DS & FALL-THRU DURING EVEN BEAT INTERVENTION 
D_ACK & !D_ACK_10) ; 


(AS_30 & !AS_40 & AI) CLOCK STATUS AND CAPABILITIES 
OUT TO THE FUTUREBUS+ 
(!1CS_AS~ & !IV & !ADDLACK~ & DS & !WR & CLOCK DATA, STATUS AND CAPABILITY OUT 
D_ACK & !DS_10) DURING ODD BEAT READ ACCESSES , 
(!CS_AS~ & !IV & SADD_ACK~ & DS & !WR & CLOCK DURING ODD BEAT READ ACCESSES 
D_ACK & !D_ACK_10) 
(!CS_AS~ {IV & !ADD_ACK~ & WR & DS & CLOCK STATUS AND CAPABILITY OUT DURING 
!ID.ACK & !DS_10) ODD BEAT WRITE ACCESSES 
(!CS_AS~ {IV & !ADDLACK~ & WR & DS & CLOCK DURING ODD BEAT WRITE ACCESSES 
!DLACK & D_ACK_10) : 
(!CS_AS~ & SIV & !ADDLACK~ & WR & DS & CLOCK DURING ODD BEAT WRITE ACCESSES 
ID.ACK & ADD_ACK_10~ ) 
(!CS_AS~ & !IV & !ADDLACK~ & !DS & !WR & CLOCK DURING EVEN BEAT READ ACCESSES 
FLINITACC~ & !D_ACK & DS_10) 
(1CS_AS~ & SIV & !ADD_ACK~ & !DS & !WR & CLOCK DURING EVEN BEAT READ ACCESSES 
F_INITACC~ & !D.ACK & D_ACK_10) 
(!CS_AS~ & !IV & !ADDLACK~ & WR & '!DS & CLOCK DURING EVEN BEAT WRITE ACCESSES 
F_LINITACC~ & D_ACK & DS_10) 
($CS_AS~ & !IV & !ADDLACK~ & WR & 'DS & CLOCK DURING EVEN BEAT WRITE ACCESSES 
FLINITACC~ & DLACK & !D_ACK_10) 
(!CS_AS~ & IV & !ADDLACK~ & DS & DK_IN & CLOCK DURING ODD BEAT INTERVENTION ACCESS 
IDACK & !DKI_10) 
(!CS_AS~ & IV & !ADDL_ACK~ & DS & DK_IN & CLOCK DURING ODD BEAT INIERVENTION ACCESS 
!D.ACK & D_ACK_10) 


CKO_D_S_C 


a 
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15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


(!1CS_AS~ & IV & !ADD_ACK~ & DS & DK_IN & * CLOCK DURING ODD BEAT INTERVENTION ACCESS 
!D_ACK & ADD_ACK_10~ ) ; : 
(!CS_AS~ & IV & !ADD_ACK~ & F_INITACC~ & * CLOCK DURING EVEN BEAT INTERVENTION ACCESSES 
D.ACK'& !DS & DILIN & !DII_10) 
(!1CS_AS~ & IV & !ADD_ACK~ & F_INITACC~ & CLOCK DURING EVEN BEAT INTERVENTION ACCESSES 
D.ACK & !DS & DILIN & !D_ACK_10) 
(CS.AS~ & AS_3SO) ; * CLOCK DURING DISCONNECT 


(ICS_AS~ & !IV & AS_30 & !DS) MAKE DI HIGH FROM DS BEING LOW 
(!1CS_.AS~ & !IV & DI & !DS_10) HOLD DI HIGH (DI* ON F_BUS IS LOW) UNTIL 10NS AFTER THE 
ODD DATA BEAT STARTS FOR READS AND WRITES 
WR & ADD_ACK_10~) HOLD DI FOR THE INITIAL WRITE ACCESS 
IWR & HOLD DI HIGH UNTIL 10NS AFTER D_ACK DURING READS 
!D_ACK_10) ; : 
( {CS_AS~ {IV & WR & DI & !ADD_ACK~ HOLD DI HIGH UNTIL 10NS AFTER D_ACK DURING WRITES 
' & D_ACK_10) 
({CS_AS~ & IV & AS_30 & !F_INITACC~) START DI DURING THE INITIAL ACCESS OF INTERVENTION 
(!CS_AS~ & IV & DI & ADD_ACK_10~) . HOLD DI FOR THE INITIAL INTERVENTION ACCESS 
(!CS_AS~ & IV & DILIN & !DS & DURING INTERVENTION WAIT UNTIL DI_IN IS VALID 
!ADD_ACK~ ) BEFORE BRINGING DI HIGH’ ; 
IV & DI & !ADD_ACK~ & !DK) HOLD DI HIGH UNTIL 10NS AFTER THE ODD DATA BEAT 
IV & DI & !ADD_ACK~ & STARTS DURING INTERVENTION 
: !DKI_10) rae ous 
(1CS_AS~ & IV & DI & !ADD_ACK~ & HOLD DI HIGH UNTIL 1ONS AFTER D_ACK DURING INTERVENTION 
D_ACK_10) ; 


= (!CS_AS~ IV & DS & IWR & 7 MAKE DK HIGH FROM DS BEING HIGH (DS* ON F_BUS IS LOW) 
!ADD_ACK~ & D_ACK) — AND D_ACK IS HIGH DURING READ ACCESSES 
IV & DS & WR & !ADD_ACK~) MAKE DK HIGH FROM DS BEING HIGH DURING WRITES 
IV & DK & !ADD_ACK~ & HOLD DK HIGH (DK* ON F_BUS IS LOW) UNTIL lONS AFTER 
. “DS.10)° THE EVEN DATA BEAT STARTS FOR READS OR WRITES 
(!CS_AS~ IV & DK & !ADD_ACK~ & HOLD DK HIGH UNTIL 1ONS AFTER. D_ACK 
IWR & D_ACK_10) i 
( !CS_AS~ 'IV & DK &. !ADD.ACK~ & HOLD DK HIGH. UNTIL 10NS AFTER D_ACK DURING WRITES 
WR & !D-ACK.10) ; 
-IN & DS & !ADD_ACK~) " DURING INTERVENTION WAIT UNTIL DK_IN IS VALID 
!ADD_ACK~ & !DI) " HOLD DK HIGH UNTIL 10NS AFTER THE EVEN DATA BEAT 
!ADD_ACK~ & !DII_10) " STARTS DURING INTERVENTION 
!ADD_ACK~ & !D_ACK_10) ; 


('CS_AS~ & 


& 
(!CS_AS~ & & 


Sh Sk GR Ok 3h Ath Sk 








15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


MODULE S.GAL 


TITLE 'S_GAL2, THIS IS T 


S.GAL2.ABL 


RUSTY MEIER 02.22.90! 


S.GAL2 device 
CLK pin 
AS pin 
CcsS~ - pin 
pin 
pin 
pin 
pin 
pin 


2.. 


*P2OV8R' ; 


1; 
23. 


33° 


4; 
5; 
63 
Ts 
8; 


vcc pin 
ACIP~ pin 
CS_AS ~ pin 
AREQA ~ pin 
AREQ~ pin 
F_LINITACC~ pin 
AK pin 


_LEI_LADD_CM pin 


HE FUTUREBUS+ ADDRESS PHASE CONTROLLER GAL 


243 
233 
223 
21; 
20; 
19; 
183 . 
17; 


pin 9; WRITE~ pin 16; 
pin 10; LEI_S_C pin 15; 
pin 11; DK : pin 14; 
pin 12; - OE~ ‘pin 13; 
EQUATIONS 
'CS_AS~ = (!CS~ & AS); 
JAREQA~ := (AS) ; 


IF CHIP SELECTED AND FUTUREBUS+ ’AS’ IS VALID BRING LOW 


SYNCHRONIZE FUTUREBUS+ AS* TO ON-BOARD CLOCK IN PREPARATION TO 
PRODUCE AREQ~. 


JAREQ ~ s= (!1CS~ & AS & AS_30 & SECOND SYNCHRONIZATION STAGE, INCLUDING CS~, AS, AND DELAYED AS 
!AREQA~ ) . TO PRODUCE DRAM CONTROLLER ACCESS REQUEST 
# (SAREQA~ & !ACIP~) ; * HOLD UNTIL DRAM ACCESS IS FINISHED - - 


IF_INITACC~ = (!CS~ & AS & ADD_ACK~ ) ® START THE INITIAL ACCESS 
# ('CS~ & AS & !FLINITACC~ & DS & !DK); * CONTINUE INITACC~ UNTIL THE FUIUREBUS+ ODD 
id BEAT IS IN PROGRESS 


AS) IF CHIP SELECTED BUS ACCESS MAKE AK VALID 
AK & AS_30) : HOLD UNTIL END OF ACCESS AND STATUS IS VALID 
AK & !ACIP~) ; OR UNTIL DRAM ACCESS IS COMPLETED 


= (AS_20) ; LATCH THE INPUT ADDRESS AND COMMAND 


(AT) ENABLE ADDRESS ONTO BOARD WHILE AI IS HIGH 
(AS & !AS_30) ENABLE ADDRESS ONTO BOARD FROM AS UNTIL 3ONS AFTER AS 
(!CS~ & AS & AS_30 & WR) ENABLE DATA ONTO BOARD DURING WRITE ACCESS 
(!CS~ & AS & AS_30 & IV) ENABLE DATA ONTO BOARD DURING INTERVENTION 
(CS~) 3 ENABLE DATA ONTO BOARD IF NOT CHIP SELECTED 


(AS & AS_30 & !AI_IN) LATCH THE INPUT STATUS AND CAPABILITY 
('LET_S.C & AK) ; 


!{LEI_S_C 


“SRM AR AR AR HE I 


END ; 





899-NV 


AN-668 


15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


MODULE MEM. GAL2 

TITLE 'MEM_GAL2, THIS IS THE FUTUREBUS+ ACCESS DELAY LINE CONTROLLER GAL 
MEM_GAL2.ABL 

RUSTY MEIER 1101.89! 


OL-E 


MEM_GAL2 device 
pin 


pin 
pin 
pin 
pin 
' pin 
pin 
pin 
- pin 
pin 
pin 
pin 


EQUATIONS 


"P2OVEC!' ; 

vec 
__ED~ 
_ EVEND~ 

INITODD~ 
F_DE~ 
F_DO~ 
INITACC~ 
ENEV ~ 
ENOD ~ 
oDDD ~ 
oD~ 
NC 


pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 


243 
233 
223 
21; 
203 
19; 
18; 
17; 
16; 
15; 
14; 
13; 


{EVEND ~ 


SINITODD ~ 


INITIAL EVEN WRITE 


= (!CSGAREQ~ & ‘SINITACC~ & !ADD_ACK~ & !READ & 
DT_STB & F_DE~ & !ENEV~ & !B1)- 

#(ICSGAREQ~ & !INITACC~ & !ADD_ACK~ & !ENEV~ & © 
1030~ & READ & !Bl) _ . 

# (!CSGAREQ~ & !INITACC~ & !ADD.ACK~ & DT_STB & * INITIAL ODD READ 

F_DE~ & READ & B21). , 

# (AS & !CSGAREQ~ & INITACC~ & !ADD_ACK~ & !ENEV~ & * START 'EVEND~' FROM RISING OR FALLING 
DT_STB & F_DE~ & !B1) " 'DT_STB' DEPENDING UPON Bl 

# (AS & !CSGAREQ~ & INITACC~ & !ADD_ACK~ & !ENEV~ & 
IDT_STB & F_DE~ & Bl) 

# (!ED~ & !ENEV~ & E30~); 


INITIAL EVEN READ 


" "ENEV~' ENDS THIS TERM 


® START DURING AN INITIAL ACCESS TO THE ODD 
* MEMORY BANK. THIS OUTPUT IS USED TO PROVIDE 
" AN INITIAL ‘COLINC' SIGNAL TO BANK 0 SO 

" THAT THE NEXT SEQUENTIAL ACCESS TO THE EVEN 
" BANK 0 RETRIEVES THE CORRECT DATA. 


* DELAYED VERSION OF EVEN ACCESS 
" '"DT_STB* 


= (!ICSGAREQ~ & !INITACC~ & !ADD_ACK~ & 
te 020~ & 030~ & READ & B1); 


‘ENEV~ & DT_STB & !B1) 
1INITACC~ & !ADD_ACK~ & DT_STB & 030 & 
READ & Bl) 

INITACC~ & !ENEV~ & !DT_STB & Bl); 

!ENOD~ & DT_STB & B21) 

NINITACC~ & !ADD_ACK~ & DT_STB & E30 & 
rar READ & {B1) 

INITACC~ & !ENOD~ & !DT_STB & !BL); 


" DELAYED VERSION OF ODD ACCESS 
* ‘DT_STB' 





LL-E 





15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


tINITACC~ 


TH FEAR AR RE UE RHE HE HEHEHE 


# 
# 
# 

# 
# 


(!CSGAREQ~ & ADD_ACK~ & AS) 
(HINITACC~ & E30~ & !Bl & AS) 
( LINITACC ~ O030~ & Bl & AS); 


& 
(!1CSGAREQ~ & !INITACC~ & !ADD.ACK~ & !READ & !B1) 
(ICSGAREQ~ & !INITACC~ & !ADD.ACK~ & !030~ & !READ & Bl) 
(!CSGAREQ~ & !INITACC~ & !ADD_ACK~ & !0350~ & READ & !B1) 
(ICSGAREQ~ & SINITACC~ & !ADD_ACK~ & E30~ & OD~ & 030~ 

& READ & Bl) 
\ADD_ACK~ & !SLE80~ & !050~ & INITACC~) 
SGAREQ~ & !ADD_ACK~ & E30~) ; 


( ICSGAREQ~ 
(!ENEV~ & 


( }CSGAREQ ~ 
( ICSGAREQ ~ 


\INITACC~ & !ADD_ACK & Bl & !READ) 
SINITACC~ & !ADD_ACK & 030~ & ED~ & E30~ & 
READ & !B1) 
(ICSGAREQ~ & !INITACC~ & !ADD_ACK~ & !E30~ & READ & B21) 
(ICSGAREQ~ & INITACC~ & !ADD_ACK~ & !LO80~ & !E30~) 
(1ENOD~ & !CSGAREQ~ & !ADD_ACK~ & 030~); 
(!CSGAREQ~ & !INITACC~ & !ADD_ACK~ & !ENOD~ & DT_STB & 
F.DO~ & !READ & B1) 
(!CSGAREQ~ & LINITACC~ & !ADD_ACK~ & READ & Bl & 
. \ENOD~ & !E30~) 
(ICSGAREQ~ & !INITACC~ & !ADD_ACK~ & DT_STB & F_DO~ & 
READ & !B1) 


(AS & ICSGAREQ~ & INITACC~ & !ADD_ACK~ & SENOD~ & 


!DT_STB & F_DO~ & !B1l) 
(AS & ICSGAREQ~ & INITACC~ & !SADDLACK~ & !ENOD~ & 
DI_STB & FLDO~ & Bl) 
(!0D~ & !ENOD~ & 0350~) ; 


& 
IC 

(ICSGAREQ~ & !INITACC~ & !ADD_ACK~ & !E30~ & !READ & !B1) 
& 
& 


END 'INITACC~' WITH '030~' OR ‘E3O~'* 
DEPENDING UPON THE STATE OF Bl 


INITIAL EVEN WRITE 
INITIAL ODD WRITE 
INITIAL EVEN READ 
INITIAL ODD READ 


SUBSEQUENT ACCESSES 
HOLD VALID UNTIL ' !E30~! 


INITIAL EVEN WRITE 
INITIAL ODD WRITE 
INITIAL EVEN READ 


INITIAL ODD READ 


SUBSEQUENT ACCESSES 
HOLD VALID UNTIL !050~' 


INITIAL ODD WRITE 
INITIAL ODD READ 
INITIAL EVEN READ 


START ODD DELAY FROM EITHER 
RISING OR FALLING 'DT_STB‘ 


* DEPENDING UPON Bl. 


‘ENOD~ * ENDS THIS TERM 
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15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


MODULE MEM_GAL1 


TITLE *MEM_GAL1, THIS GAL CONTAINS FUTUREBUS+ READ AND WRITE CONTROL SIGNALS. 


RUSTY MEIER 


1016.89" 


MEM.GAL1 device ‘'P22V10' 


pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin: 
EQUATIONS 
{EN_F_DO~ 
{ACIP~ ( \EVEND ~ ) 
( fE1LO~):- 
( {ODDD ~ ) 
( 1010~) 
(WLEO ~ ) 
(WLEL~ ) ; 
(IREAD & 
( IREAD 


# 
# 
# 
# 
# 
# 
# 


(IREAD & 
- (READ 


th Il 


th tl 


3 Il 


( 'DACK & 
( 'D-ACK & 


3 Ok Sth Oe Ah He II 


vec 
CPU_WE~ 
EN_F_DO~ 
ACIP~ 
WLEO ~ 
WLE1~ 
WE~ 

READ 
D_ACK 
EN_F_D1~ 
Iv 


ADD_ACK~*: 


( SADD_ACK~ . & AS & DT. 


!EVEND~ ).- 
& !E10~).; 


!oDDD~ ) 


pin 24; 
pin 23; 
pin 22; 
pin 21; 
pin 20; 
pin 19; 
pin 18; 
pin 17; 
pin 16; 
pin 15; 
pin 14; 
pin 13; 


(IADD_ACK~& AS & DI_STB & !CSGAREQ~ & READ & !Bl) _ 
STB & !CSGAREQ~ & READ & Bl); 


& !010~);3;..-. 


(cscaREQ~ & !READ) 
(CSGAREQ~ & 
(IWR & ICSGAREQ~ & 
(READ & !CSGAREQ~ & 
1( (CSGAREQ~ ) 
(ID.ACK & !CSGAREQ~ & READ & E20~ & !Bl & AS) 
(IDLACK & !CSGAREQ~ & READ & 020~ & Bl & AS). 
(I1CSGAREQ~ & READ & !020~ & !Bl & AS) 
('\CSGAREQ~ & READ & 
ICSGAREQ~ & 


ICSGAREQ~ & 


!CPU_LWE~ ) ; 
IIV) 
tIV) ; . 


{E20~ & Bl & AS) 


SREAD & ELO~ & !Bl & AS) 
TREAD & OLO~ & Bl & AS) 


ENABLE READ LATCH OUTPUTS FOR BANK 0 


INDICATES THAT A DRAM ACCESS IS IN PROGRESS 


" THIS SIGNAL RELIES ON THE PULSE WIDTH OF 'EVEND' 
" 


TO GUARANTEE APPROXIMATELY 40-60 ns PULSE WIDTH 
FOR THE WRITE LATCH FOR BANK O ‘WLEO~'. 
THIS SIGNAL RELIES ON THE PULSE WIDTH OF ‘EVEND' 
TO GUARANTEE APPROXIMATELY 40-60 ns PULSE WIDTH 
FOR THE WRITE LATCH FOR BANK 1 'WLE1~'. 


WRITE ENABLE TO THE DRAM ARRAY 


" GENERATE READ SIGNAL AND HOLD UNTIL  AREQ~ IS HIGH 


UNLESS INTERVENTION 


_FUTUREBUS+ ACCESS ACKNOWLEDGE HANDSHAKE, 
.HOLD DURING READ 


HOLD DURING WRITE’. 

TWO TERMS WERE USED FOR BOTH 
READS AND WRITES. _ 

HOLD DURING WRITE © 

HOLD DURING WRITE 





ELE 





15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


# (!CSGAREQ~ & !READ & !010~ & !Bl & AS) 
# (!CSGAREQ~ & !READ & !ELO~ & Bl & AS) ); 

‘EN_.F_DL~= (!ADD.ACK~ & AS & !DT_STB & !CSGAREQ~ & READ & !B1) *" ENABLE READ LATCH OUTPUTS FOR BANK 1 
# ({ADD_ACK~ & AS & DI_STB & !CSGAREQ~ & READ & B21); 


END; 


MODULE MEM._GAL3 eat : 

TITLE *MEM_GAL3, THIS. GAL IMPLEMENTS THE RANDOM LOGIC THAT WAS USED IN 
THIS DESIGN. ; 
RUSTY MEIER 1025.89' 


MEM_GAL3S device ‘'P16V8R';. 

CLK pin vec pin 20; 
“AREQ~ pin CSGAREQ~ pin 19; 
CcS~ pin RRFRQ~ pin 18; 
‘READ pin RFIP~ pin 17; 
‘E30~ pin DTACK~ pin 16; 
E80~ pin ADDIACK~ pin 15; 
030~ pin L080 ~ pin 14; 
080~ pin LE80~ pin 13; 
G_F_BUS~ pin RFSH~ pin 12; 
GND - pin OE~ pin 11; 
EQUATIONS 


!ADD_ACK~ (!G_F.BUS~ & !DTACK~ & !CS~ & DRAM ADDRESS PHASE COMPLETE, 
READY TO START DATA TRANSFER PHASE. 


(IRFRQ~ & RFIP~); - " DO EXTERNALLY CONTROLLED REFRESH 
“(ICS~ & JAREQ~. & !G_F_BUS~) ; DRAM ACCESS IN PROGRESS 
-(1080~ & !ADD_ACK~) 8 | "© LATCH THAT 080~ HAS TRANSITIONED LOW 
(!L080~ & 030~ & !ADD_ACK~) ; 

(!E80~ & !ADD_ACK~) . LATCH THAT E80~ HAS TRANSITIONED LOW 
(!LE80~ & E30~ !ADD_ACK~); 


we 


KF UOONOAAHhAND FE 


oO. 


{RFSH ~ 
ICSGAREQ ~ 
tL080 ~ 


'LE80 ~ 


Soll Fhe ON. 


END; 
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15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


MODULE 
TITLE 


MEM_GAL4 7 

*MEM_GAL4, THIS DEVICE IS USED TO CONTROL THE BANK 0 CAS INPUTS 

OF THE DRAMS, ALONG WITH THE READ LATCH FOR BANK 0 (RLEO), AND THE 
COLUMN INCREMENT INPUT (COLINCO) TO THE DRAM CONTROLLER FOR BANK 0.' 

" THE ECAS~ INPUT ALLOWS A LOCAL CPU (AND, OR I/O CONTROLLER IF USED) TO 


" CONTROL THE CAS INPUTS TO THE BANK 0 DRAMS. WHEN CSGAREQ~ IS LOW THE 
" FUTUREBUS ACCESS CONTROLS THE CAS INPUTS TO THE BANK O DRAMS. 
" RUSTY MEIER 1016.89 , 


MEM_GAL4 


READ 
BE~0 
BE~1 
BE~2 
BE~ 3 
ECAS~ 
ICAS~0O 
CSGAREQ ~ 
INITODD ~ 
E10~ 
E40 ~ 

GND 


EQUATIONS 
IcAS~0 


device 


*P20V8C' 5 


pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 


vec 
cs~0o 
CcCAS~0O 
CAS~1 
RLEO ~ 
COLINCO 
040~ 
030~ 
CAS~2 
CAS~3 
CS~3 
ODDD~ - 


pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 
pin 


243 
233 
223 
21; 
20 5 
19; 
18; 
17; 
16; 
153 
14; 
13; 


(!ECAS~ & 


{ICAS~O & 


IBE~O & CSGAREQ~ ) 


(ICSGAREQ~ & READ & !ODDD~ & 


TICAS~O & 


!BE~ 0) 


(!cS~0O & 


ICSGAREQ~ & READ & 040~ & 


(!cS~0O & 


ICSGAREQ~ & READ & !RLEO~ & 


fICAS~O & 
!1ICAS~O & 


( 1CSGAREQ~ & 


{READ & 


(!ECAS~ & 


1ICAS~O & 


(!CSGAREQ~ & READ & 


{E10 ~ 
IBE~1 
!ODDD ~ 


& !ICAS~O & 


& CSGAREQ~ ) 
& SICAS~O & 


IBE~ 0) ; 


IBE~ 1) 


(!CAS~1l & 
(!CAS~1 & 


ICSGAREQ~ & READ 
!ICSGAREQ~ & READ 


& 040~ & 


tICAS~O & 


(!CSGAREQ~ & 
(READ & !040 


$ID FR HEHE HON FRE HET 


'READ & 
A 


{E10 ~ 


& !IRLEO~ & 
& !ICAS~O & 


(RLEO~ & READ & ODDD~) ; 


fICAS~O & 


IBE~ 0) 
{BE~ 0) 


'BE~ 1) 
IBE~ 1) 


!IBE~1) ; 


CAS~ DURING NON-F_BUS ACCESS 

START FLBUS READ CAS~ 

HOLD F_BUS READ CAS~ 

HOLD F_BUS READ CAS~ UNTIL DATA IS LATCHED 
F_BUS WRITE CAS~ 


CAS~ DURING NON-F_BUS ACCESS 

START F.BUS READ CAS~ 

HOLD F_BUS READ CAS~ 

HOLD F_BUS READ CAS~ UNTIL DATA IS LATCHED 
F_BUS WRITE CAS~ 


RLEO~ HIGH TO LATCH BANK O READ DATA 
HOLD RLEO~ HIGH 





GLE 





15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


COLINCO 


# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 


1( (CSGAREQ~ ) 
(!COLINCO & INITODD~ & 030~ & READ) 
(!COLINCO & ELO~ & 030~ & READ) 
(!CSGAREQ~ & !E40~ & 030~ & READ) 
(!CSGAREQ~ & INITODD~ & 030~ & READ) 
(!COLINCO & E40~ & !READ) 
(!CSGAREQ~ & E40~ & !READ) ); 
(!1ECAS~ & !ICAS~O & !BE~2 & CSGAREQ~) 
(!CSGAREQ~ & READ & !ODDD~ & !ICAS~O & !BE~2) 
(ICAS~2 & ICSGAREQ~ & READ & 040~ & !ICAS~O & !BE~2) 
(1CAS~2 & ICSGAREQ~ & READ & !RLEO~ & !ICAS~O & !BE~2) 
(!CSGAREQ~ & !READ & !El0O~ & !ICAS~O & !BE~2); 
(1ECAS~ & !ICAS~O & !BE~3 & CSGAREQ~) 
(ICSGAREQ~ & READ & !0DDD~ & !ICAS~O & !BE~3) 
(1CS~3 & ICSGAREQ~ & READ & 040~ & !ICAS~O & !BE~3) 
(1CS~3 & !CSGAREQ~ & READ & !RLEO~ & !ICAS~O & !BE~3) 
(ICSGAREQ~ & !READ & !ELO~ & !ICAS~O & !BE~3); 


COLINCO LOW IF NOT ACCESSING 

HOLD LOW DURING READ UNTIL !030~ UNLESS !INITODD~ 
HOLD LOW DURING READ 

COLINCO LOW DURING READ ACCESSES 

COLINCO LOW DURING READS UNLESS !INITODD~ 

HOLD LOW DURING WRITE UNTIL !E40~ 

COLINCO LOW DURING WRITE ACCESSES 


CAS~ DURING NON-F_BUS ACCESS 

START F_BUS READ CAS~ 

HOLD F_BUS READ CAS~ : 

HOLD F.BUS READ CAS~ UNTIL DATA IS LATCHED 
F_BUS WRITE CAS~ 

CAS~ DURING NO-F_BUS ACCESS 

START F_BUS READ CAS~ 

HOLD F_BUS READ CAS~ 

HOLD F_BUS READ CAS~ UNTIL DATA IS LATCHED 
F_BUS WRITE CAS~ 
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15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


MODULE § MEM_GAL5 
TITLE 'MEM_GAL5, THIS DEVICE IS USED TO CONTROL THE BANK 1 CAS INPUTS 
OF THE DRAMS, ALONG WITH THE READ LATCH FOR BANK 1 (RLEl), AND THE 
COLUMN INCREMENT INPUT (COLINC1) TO THE DRAM CONTROLLER FOR BANK 1.' 
" THE ECAS~ INPUT ALLOWS A LOCAL CPU (AND, OR I/O CONTROLLER IF USED) TO CONTROL 
" THE CAS INPUTS TO THE BANK 1 DRAMS. WHEN CSGAREQ~ IS LOW THE FUTUREBUS 
" ACCESS CONTROLS THE CAS INPUTS TO THE BANK 1 DRAMS. 
" RUSTY MEIER 1016.89 
device ‘'P20V8C'; 
pin vec pin 24; 
pin cS~O pin 23; 
pin cAS~0O pin 22; 
pin cAS~1 pin 21; 
pin RLE1L~ pin 20; 
pin COLINCl pin 19; 
pin WE_F_D~ pin 18; 
pin 040~ pin 17; 
pin CAS~2 pin 16; 
pin CAS~3 pin 15; 
pin ; CS~3S pin 14; 
pin : 010~ pin 13; 
EQUATIONS 
{CAS~0 (1ECAS~ & !ICAS~O & !BE~O & CSGAREQ~) CAS~ DURING NON-F_BUS ACCESS 
(!CSGAREQ~ & READ & !EVEND~ & !ICAS~O & !BE~0) START F_BUS READ CAS~ 
(1CS~O & ICSGAREQ~ & READ & E40~ & !ICAS~O & !BE~O) HOLD F_BUS READ CAS~ 
(!1CS~O & !CSGAREQ~ & READ & !RLEL~ & !ICAS~0O & !BE~0) HOLD F_BUS READ CAS~ UNTIL DATA IS LATCHED 
(!CSGAREQ~ & !READ & !010~ & !ICAS~O & !BE~0); F_BUS WRITE CAS~ 
(1ECAS~ & !ICAS~O & !BE~1.& CSGAREQ~) meee " CAS~ DURING NON-F_BUS ACCESS 
(ICSGAREQ~ & READ & !EVEND~ & !ICAS~O & !BE~1) “START F_BUS READ CAS~ 
({CAS~1 & ICSGAREQ~ & READ & E40~ & !ICAS~O & !BE~1) ‘* HOLD F_BUS READ CAS~ _ 
(I1CAS~1 & ICSGAREQ~ & READ & !RLEL~ & !ICAS~O & !BE~1) HOLD F_BUS READ CAS~ UNTIL DATA IS LATCHED 
(1CSGAREQ~ & !READ & !010~ & !ICAS~O & !BE~1); ‘" FLBUS WRITE CAS~ ; 
(READ & !E40~) hehe ce ditt kak, sk -RLEL~. HIGH TO LATCH BANK 1 READ DATA _ 
|. (RLEL~ & READ & EVEND~); meg " HOLD RLEl~ HIGH 
(!READ & !CSGAREQ~); .. . BR -" ENABLE-WRITE DATA THRU. 
: , " 74F543 TRANSCEIVERS 


1 Se AR AR AR HR ON HE HE FEET 
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15.0 GAL EQUATIONS WRITTEN IN ABEL FOR THE MEMORY MODULE DESIGN (Continued) 


* COLINCL 


# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 


1( (CSGAREQ~ ) 

(!COLINCl & E30~ & READ) 

(!CSGAREQ~ & ESO~ & READ) 

(I1COLINCL~ & 040~ & !READ) 

(!CSGAREQ~ & 040~ & !READ) ); 
(1ECAS~ & !ICAS~O & IBE~2 & CSGAREQ~) 
(I1CSGAREQ~ & READ & !EVEND~ & !ICAS~O & !BE~2) 
(1CAS~2 & !CSGAREQ~ & READ & E40~ & !ICAS~O & !BE~2) 
(1CAS~2 & ICSGAREQ~ & READ & !RLEL~ & !ICAS~O & !BE~2) 
(!CSGAREQ~ & !READ & !010~ & !ICAS~O & !BE~2); 
(!ECAS~ & !ICAS~O & !BE~3 & CSGAREQ~) 
(ICSGAREQ~ & READ & !EVEND~ & !ICAS~O & !BE~3) 
(1CS~3 & !CSGAREQ~ & READ & E40~ & !ICAS~O & !BE~3) 
(1CS~3 & !CSGAREQ~ & READ & !RLEL~ & !ICAS~O & !BE~3) 
(!CSGAREQ~ & !READ & !010~ & !ICAS~O & !BE~3); 


COLINC]L LOW IF NOT ACCESSING 

HOLD LOW DURING READ UNTIL !E30~ UNLESS 
LOW DURING READ 

HOLD LOW DURING WRITE ACCESS UNTIL 
COLINC1 LOW DURING WRITE ACCESS 


CAS~ DURING NON-F_BUS ACCESS 

START F_LBUS READ CAS~ 

HOLD F_BUS READ CAS~ 

HOLD F_BUS READ CAS~ UNTIL DATA IS LATCHED 
F_LBUS WRITE CAS~ 


CAS~ DURING NO-F_BUS ACCESS 

START F_BUS READ CAS~ 

HOLD F_BUS READ CAS~ : 
HOLD F_BUS READ CAS~ UNTIL DATA IS LATCHED 
F_BUS WRITE CAS~ 


fINITODD~ 


{E40 ~ 
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74F5074 
AS AS_Q (to S_GAL2 pin 21) 


25 MHz SYSTEM CLOCK 
TL/L/10772-38 


* Revised S_GAL2 AREQ~ equation 
{AREQ~ = AS_Q&AS &!ICS~ & AS_30 


# IAREQ~ & IACIP~ 
FIGURE 34. Improving Performance during the Initial Memory Module Access 


Futurebus + Slave 
Backplane Memory 
DS3886 Board 


Status & 
Re B(8:0) A(8:0 Status & 
Capability (8:0) (8:0) — Capability In 


CS_AS~ 
(from PROTOCOL_CTR Block) 


CKO_D_S_C 


TL/L/10772-39 
FIGURE 35. Status and Capability Driver Connection Diagram . 
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Futurebus+ 1/O 
Board Design 


1.0 INTRODUCTION 


This application note describes a Futurebus+ I/O board 
design. The first part of this application note contains an 
introduction to Futurebus+ and how the I/O board interfac- 
es to it. Next, a more detailed description of the Futurebus + 
protocol controller and the control lines that interface it to 
Futurebus+ and the Memory Module is presented. 


This application note implements a Futurebus+ 1/O board 
design (see Figure 7) using National Semiconductor GAL®s 
(or PAL®s) to achieve a peak transfer rate of approximately 
20 M-transfers/s (approximately.80. Mb/s using 32 data bits 
per memory bank, or 160 Mb/s using 64 data bits per mem- 


ory” bank)” during” compelled: burst “transfers.” The Future- 


bus+ protocol controller supports the compelled mode of 
operation. The word compelled refers to the fact that after 
the master gives a request for a transfer the master is com- 
pelled to wait for a response from the slave before it can 
proceed to the next transfer. This request/acknowledge 
protocol is asynchronous and edge sensitive where both 
rising and falling edges are used to transfer information. 
This application note assumes that the reader is familiar 
with the DP8422A-25 DRAM controller, GAL/PAL design, 
and Futurebus +. This application note also builds on Appli- 
cation Note 668, Futurebus+ Asynchronous Slave Memory 
Design, by adding Futurebus+ mastership capabilities to 
that design. 


1.1 Introduction to Futurebus + 

Futurebus+ is a high-performance asynchronous 64-bit 
multiplexed address/data backplane bus designed by the 
IEEE 896.1 committee for use in a wide variety of multipro- 
cessor architectures. The Futurebus+ standard is a next 
generation backplane bus standard developed to a set of 
requirements including openness, performance, and system 
facilities and flexibilities so as to not hinder systems using 
this bus for many generations of computer systems. Future- 
bus+ is a single cache coherent backplane architecture 
featuring scalability, technology independent protocols, and 
explicit provisions to extend to future applications. 


2.0 INTRODUCTION TO THE FUTUREBUS+ I/O BOARD 
DESIGN 


This Futurebus-+ I/O board design consists of the following 
blocks: 


1. Futurebus+ interface block, 
. Futurebus+ Reset and Initialization block, 
. CPU block, 
.. I/O block, 
. Local Bus Arbiter block, 
. DRAM Interface block, 
. DRAM block, 
. DRAM, local and Futurebus+ 
block, 
9. Futurebus+ Protocol and DMA controller block. 
Figure 2 is a flowchart for the |/O board becoming the Futu- 
rebus+ Master. The slave flowchart (and all details of the 
slave portion of this board) will be found in Application 


interface transceiver 


National Semiconductor 
Application Note 751 
Webster (Rusty) Meier Jr., 
David Hawley, and 

Shilpa Parikh 


Note 668, Futurebus+ Asynchronous Slave Memory De- 
sign. 


2.1 Futurebus+ Interface Block 

This block consists of the transceivers and arbitration con- 
troller that Interface to Futurebus+. It contains the DS3886 
9-bit BTL latched data transceivers, the DS3884 BTL Hand- 
shake transceivers, the DS3885 Arbitration transceivers, 
and the DS3875 Futurebus+ Arbitration Controller. 


2.2 Futurebus+ Reset and Initialization Block 

This block detects and initiates Futurebus+ initialization 
and system reset functions. These events are decoded and 
encoded within the time allocation period as given in the 
P896.1 Futurebus+ Logical Layer Specifications. Live !n- 
sertion and Live Withdrawal are not implemented in this de- 
sign since these functions were not needed. However, if an 
application requires these functions, this design can be eas- 
ily expanded to add the needed signals. 

This block monitors the -RE* signal. on the Futurebus+ 
backplane. When RE* is asserted, a counter begins count- 
ing until RE* is released. While RE* is asserted, the bus 
initialize, reset system and Faulty RE* signals are evaluat- 
ed. If system reset is detected, then RE* is driven until the 
board is reset (10 ys). When the module initiates a bus 
intialize or system reset, RE* is driven for the specified time, 
and until the on board bus initialization and reset functions 
are complete. 


2.3 CPU Block 


This block provides the local intelligence for the I/O board. 
The CPU responsibilities include: 


— programming the DRAM controllers, 
_ programming th the Futurebus + Soe ae 
_ programming | the I/O device, » 


— Programming t the DS3875 Futurebus+ Arbitration Con- 
troller, and, 


— all housekeeping chores associated with the I/O board. 
A National Semiconductor NS382GX320 was chosen as the 


_ CPU. This is a 32-bit CPU that includes an on-board instruc- 


tion and data cache. Read, Write, and 4 word Burst Read 
(with wrap around) accesses are supported to the DRAM. 
2.4 1/0 Block 

The I/O block could be any I/O davies: i.e., | Ethernet inter- 
face, FDDI interface, Hard Disk interface . . etc. 

2.5 Local Bus Al Arbiter and Address Decode Block 


This block provides ‘arbitration for the local bus on the I/O 
board. Note that to access the local DRAM, one must gain 


* access to the local bus. The local bus arbiter provides arbi- 


tration between the local bus and; 

— the CPU, 

—_ the 1/0 device, and, 

_— the Futurebus + Protocol Controller. 


The local bus is a separate synchronous address and data 
bus. The local bus arbiter accepts bus request signals from 
the above mentioned devices and issues bus grant signals. 
Only one bus grant signal is asserted at any given time. 
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Each requestor is expected to limit its own transactions 
across the bus to less than 15 ys. This allows the DRAM to 
be refreshed as required. 


When no one is requesting the bus, the arbiter gives bus 
grant to the CPU. The BG_CPU* signal is asserted follow- 
ing power up, and when bus rec request signals from the I/O 
devicé and Futurebus+ are not asserted (Idle State). Any 
bus request signal from another device asserts HOLD* to 
the CPU. When HOLD* is asserted, all the CPU aon are 
TRI-STATE®. 


The 1/0 device has been given a higher priority than the 


- Futurebus+ bus request. Thus, when the two bus request 


signals is (BR IO* and BR_FB*) are simultaneously assert- 
ed, the arbiter will issue bus grant to the |/O first. Then, 
when BR_IO* is released, the arbiter will issue bus grant to 
Futurebus +. 


The Address Decode section decodes the devices being 
addressed by generating the Chip Select (CS*) signals. The 
address space is allocated as follows: 


- 00000000 to FEFFFFFF: ‘DRAM Memory 


FFO00000 to FFE7FFFFF: Arbitration Controller Registers 


DMA Protocol Controller 
* Registers 


“I/O Device Registers 
FF8FFFFF to FFFFFFFF: Used by CPU or unused 


2.6 DRAM Interface Block 


The DRAM Interface block provides an jiertags to the local 
DRAM memory for the following devices: : 


— CPU, 


— I/O device, and, _ 
_ Futurebus + Protocol and DMA Controller. 


2.7 DRAM i Block 


For the purposes of this design a two bank DRAM system 
was designed. Each bank is controlled by a DP8421A 
DRAM Controller and is assumed to be 256k x 36 bits wide 
(82 bits data plus 4 4 parity bits bits). Therefore the total memory 
on the I/O board is 512k x 36 bits, or 2 MB. This configura- 
tion can be expanded up to 2M x 72 bits (16 MB) using the 
DP8421A DRAM Controller, or 8M x 72 bits (64 MB) using 
the DP8422A DRAM Controller. 


This Futurebus+ memory module can schieve a 20 
M-transfer/s rate during burst accesses. This performance 
is approximately 80 MB/s using 32 bits per memory bank 
and 160 MB/s ‘using 64 bits per memory bank. This per- 


” formance is calculated in Application Note #668, Future- 


bus+ Asynchronous Slave Memory Design. 
2.8 DRAM, Local ane puprepus Udit ad Transceiver 
Block 


There are two DRAM banks. Each DRAM bank has a sepa- 
rate interface to the local.1/O bus and the Futurebus+ thru 


_ data transceivers. 


The DRAM interface to the local 1/O bus is ita ‘TAF657 
transceivers. These transceivers include parity generation 
and parity checking. Any data that is being written to the 
DRAM via the local bus has parity generated and stored 
along with the data. When data is read from the DRAM to 
the local bus the parity is checked for errors. 


The DRAM interface to Futurebus is thru 74F543 trans- 
ceivers. These transceivers include read and write ) latches. 


The latches in the transceivers allow the ¢ data being read or 
written to the DRAM to be pipelined. : - 


During a DRAM read operation the two transceivers are 


transceiver based FIFO is 12 ns. Therefore the Futurebus + 
sees a 12. ns memory when reading from the DRAM. — 


Likewise a DRAM write access is acknowledged once the 
data is latched into the transceiver write latch. The actual 
write access tot the DRAM. occurs | later. : 

2.9 Futurebus+ Protocol and DMA Controller Block 


The Futurebus+ Protocol Controller contains the logic nec- 
essary to implement a high pertormances GAL based Future- 
bus+ |/O board: 


— Master and Slave capability, 
— Compelled read and write transfers, partial, sinale and 


_ address only trancactions and, 
_ Split transactions 
The Futurebus+ “Protocol Controller contains the following 


_blocks: 


— Asynchronous State Machine, — 
_ Synchronous State Machine, ae 
— DMA Local Address Register, 


— DMA Futurebus+ Address Ree and Parity 
. Generator, 


— DMA Transfer Size Counter, .. 


— Slave Address and Data Command Latches and anily 
Checkers, and 


= Master Address and Data Command Latches and Parity 


Generator. 


2.9.1 Asynchronous State Machine 

The asynchronous state machine provides: 

— high performance compelled Futurebus+ interface, 
— interface to the DMA controller, 

— interface to the DRAM controller. 

The Futurebus+ interface includes: 

— Futurebus+. arbitration controller (DS3875) interface, 


— The output clock; input latch, and direction contro! of the 
Futurebus+ latched transCeivers (DS3886), and, 


-— Futurebus+ Command, Capability, and Status interface. 


The DMA controller interface includes enables for’ the 
Futurebus+ Address Register (FAR) and the Local Address 
Register (LAR). The “LAST_XFER” output of the Transfer 
Size Counter (TSC) is used t to end t ‘the masters Futurebus + 
transaction. 


The DRAM controller interface controls the handshake sig- 
nals between the DRAM Controller Module and the Future- 
bus+ Protocol and DMA Controller Module = STB, 
D_ACK). 


2.9.2 DMA Controller (Synchronous State Machine) - 


The Futurebus+ Protocol Controller contains a simple DMA 
controller used when the I/O board becomes the Future- 
bus+ master. It is used to transfer blocks of data between 
the local DRAM and the Futurebus+. ale The DMA 
controller consists of four blocks: 


The LAR (local address register) contains the start address 
of the data block in DRAM. This can be either the source or 
destination of the transfer, depending on whether a bus 
write or read has been programmed. It is programmed from 
the data bus by the local CPU at the start of each transfer. It 
is implemented in four '573 latches. 








The FAR (Futurebus address register) contains the start ad- 
dress of the data block on Futurebus. Once again, this is 
‘independent of the direction of data transfer. It is also pro- 
grammed from the data bus by the local CPU at the start of 


each transfer. It is implemented in four ’899 latched trans-. 
ceivers, which are also used to generate the parity for the 


Futurebus address. Because the address and data bus are 
multiplexed on Futurebus+, these transceivers can also be 
used to check the address and data parity on all slave trans- 
actions as well. 


The TSC (transfer size counter) determines the number of 
words in the block DMA transfer. The 8-bit counter allows 
block sizes of up to 256 words (1 kB on a 32-bit bus) ina 
single transfer, subject to the limitations of slave. This is 
also programmed by the local CPU at the start of each 
transfer. Because it must be clocked asynchronously as the 
DMA transfer: progresses on Futurebus, it could not be im- 
plemented in the same device as the rest of the DMA state 
machine. The CPU’s DMA transfer size data is latched into 
a’578, which is loaded into a ’269 counter by the DMA state 
machine at the start of each transaction..A '541 buffer. al- 
lows the CPU to read the contents of the counter in the 
event of an error or unexpected DMA termination condition. 


The DMA state machine is implemented as part of a 
MAPL128 PLD. Although only a few of the available product 
terms are used in this design, the additional room is avail- 
able for implementing more sophisticated DMA control algo- 
rithms. This DMA controller waits for the CPU to signal, via 


an external I/O control register bit, that the DMA registers 


described above have been programmed and the transfer is 
ready to go. The synchronous DMA state machine requests 
first Futurebus+, then the local bus. Once both buses are 
available, it enables the addresses onto both the local and 
system buses and starts the asynchronous Futurebus+ 
master state machine. With each data transfer, the transfer 
counter is decremented. Once it reaches zero, the master 
state machine signals the DMA state machine. The DMA 
state machine checks to ensure that the transfer has com- 
pleted successfully, and interrupts the CPU. The DMA con- 
troller is now ready to execute another transfer. | 


2.9.3 Slave Address and Data Command Latches and 
Parity Checkers 


The slave address and data command latches hold the ad- 
dress and data command of the current Futurebus+ trans- 
action. 


2.9.4 Master Address and Data Command Latches and 
Parity Generator 


The master address and data command latches hold the 
address and data command of the current Futurebus+ 
transaction when the I/O board is the current master of 
Futurebus+. These command latches are loaded by the 
on-board CPU before starting the Futurebus+ transaction. 


3.0 FUTUREBUS+ SYSTEM TIMING CALCULATIONS 


3.1 Maximum Time during a Master Read Access (Mas- 
ter reading data from slave) from the master generating 
DS to the master generating the next edge of DS is 89 ns. 
This is based upon the assumption that the DT__STB re- 
quest/D_ACK acknowledge between the protocol control- 
ler and the memory module (of the I/O board) will be less 
than or equal to the speed of the Futurebus+ request/ac- 
knowledge handshake signals (DS, DK, and DI). 


Parameter | 
_ (Maximum Delays) 


Single | Total 
Delay | Delay 


Master’s GAL Generates DS (assume 
10 ns GAL) . 

Master’s Handshake Transceiver, 

DS (DS3884). 

Futurebus+ Delay 

Slaves Handshake Transceiver, 

DS (DS3884) 

Clock Out to Futurebus+ Next Piece of 
Data to Write to the Master 

Delay line (+2 ns), 10 ns Tap*** 
Slaves GAL Produces DK or DI 
(assume 10 ns GAL) 

Slaves Handshake Transceiver, 
DK/DI (DS3884) 

Futurebus+ Delay 

Master’s Handshake Transceiver, 
DK/DI (DS3884) 

Delay Line (+2 ns), 10 ns Tap*** 
Master’s GAL Generates DS .. 
ieesumne 10 ns GAL) 


Typical Time during a Master. Read acces (Master 

reading data from slave) from the master generating DS 
to the master generating the next edge of DS is 58 ns: 

' Parameter | (inns) 

(Typical Delays) ie Total 

Delay | Delay 


Master’s GAL Generates DS 

(assume 10 ns GAL) 

Master’s Handshake Transceiver, 

DS (DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver, 

DS (DS3884) 

Clock Out to Futurebus+ Next Piece of 


Data to Write to the Master 


Delay Line (+2 ns), 10 ns Tap 
Slaves GAL produces DK or DI 
(assume 10 ns GAL) 

Slaves Handshake Transceiver, 
DK/DI (DS3884) 

Futurebus+ Delay 

Master’s Handshake Transceiver, 
DK/DI (DS3884) 

Delay Line (+2 ns), 10 ns Tap 
Master’s GAL generates DS 
(assume 10 ns GAL) 


This gives a typical transfer rate of greater than 
17 M-transfers/s during the Data Phase of the 
Futurebus+ Transfer. 


***The 10 ns delay line used to compensate for possible skew between the 
Latched Transceiver (DS3886) and the Handshake Transceiver 
(DS3884). 
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3.2 Maximum time during a Master Read Access (Master 
reading data from slave) from the master generating DS 


to the master generating the next edge of DS is 89 ns. This 


is based upon the assumption that the DT_. STB request/ 
D__ACK acknowledge between the protoco! controller and 
the memory module (of the I/O board) will be less than or 
equal to the speed of the Futurebus+ RequESU ECenOWE 
edge handshake signals (DS, DK, and DI). 


Parameter 


(Maximum Delays) Total 


| inns) 

| Single 
Delay | Delay 

Master’s GAL Generates DS 

(assume 10 ns GAL) 

Master’s Handshake Transceiver, 

DS (DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver, 

DS (DS3884) 

Delay Line (+2 ns), 10 ns Tap*** 

Slaves GAL Produces DK or DI 

(assume 10 ns GAL) 

Slaves Handshake Transceiver, 

DK/DI (DS3884) 

Futurebus+ Delay 

Master’s Handshake Transceiver, 

DK/DI (DS3884) 

Clock Out to Futurebus+ Next Piece of 

Data to Write to the Slave 

Delay Line (+2 ns), 10 ns Tap*** 

Master’s GAL Generates DS 





(assume 10 ns GAL) 
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Typical time during a Master Read Access (Master read- 
Ing data from slave) from the master generating DS to the 
master generating the next edge of DS is 58 ns: 
Parameter | (inns) | 
~ (Typical Delays) 
Delay | Delay 


Master's GAL Generates DS 
(assume 10 ns GAL) © 

Master’s Handshake Transceiver, 
DS (DS3884) 

Futurebus+ Delay 

Slaves Handshake Transceiver, 
DS (DS3884) 

Delay Line (+2 ns), 10 ns Tap*** 
Slaves GAL Produces DK or DI 
(assume 10 ns GAL) 
Slaves Handshake Transceiver, 
DK/DI (DS3884) 7 
Futurebus+ Delay 

Master's Handshake Transceiver, 
DK/D! (DS3884) 

Clock Out to Futurebus+ Next Piece of 
Data to Write to the Slave 

Delay Line (+2 ns), 10 ns Tap*** 
Master’s GAL Generates DS 
(assume 10 ns GAL) 


This gives a typical transfer rate of greater than 
17. M-Transfers/s during the Data Phase of the 
Futurebus+ Transfer. 

***The 10 ns delay line used to compensate for possible skew between the 
Latched Transceiver (DS3886) and the Handshake Transceiver 
(DS3884), 

4.0 DESIGN CONSIDERATIONS OF THIS ARPRICATION, 

NOTE — 


4.1 CSR Space 


CSR registers are implemented in DRAM, more sophisticat- 
ed implementations are possible. 














€8-€ 


aa 
Controller 


Futurebust+ "Bg. CPU, 1/0 device, and | 
; Futurebust Protocol [ Bank 1 74F657 


Waster and Slave 
local bus request Controller DRAM 
and acknowledge Interface Logic |: ; Bank 0 74F657 
: : Data Buffer & 
an Parity Gen/Checker 
; Parity error 


FAR, MAC, 
MOC) SYNCHRONOUS DATA BUS - SYNCHRONOUS DATA BUS 


LOCAL ADDRESS BUS 


Futurebus+ 


Aadress 74F899 


ae Local Address ~ | (tSc) Transfer (FAR) hae 
2 Futurebust | Futurebust Farty "| FBUS# Address 


Register Size 
aie Parity Address Register 


Fs 
; , (Readable and Register & Parity 
: Writeable) (With Parity Checker 
Slave Address and Master Address and late = Generator) 
& Date Parity 


Data Command Latch Data Command Latch 
Checker 


and Parity Checker and Parity Generator 
FUTUREBUS+ PROTOCOL A(0..31) & 
& DNA CONTROLLER | 


DS3885 Command/Parity Bits 
: ._. Futurebus+ Address, Data, Parity bus 


Arbitration 
and DS3884 ; 7 
Handshake DS3886 Latched i 7 AD(0..31) & Parity 


Transceivers Data BTL , 
Transceivers Handshake BIL DS3886 
Transceivers fo’ 9-Bit, BTL Latched 
Transcelvers 
(Data & Address) 


FUTUREBUS+ AD (0..31)* & Parity FUTUREBUS+ 


TL/F/11155-1 


FIGURE 1. Futurebus+ I/O Board 
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Date ... November 5, 1990 


The 1/0 Board desiring to 
access Futurebust 


Are there any 1/0 board 
DMA requests still Pending? 


CPU loads Local Address Counter (with source or destination address), 
Futurebus+ Address Counter (with destination or source address), and | 
Transfer Size Counter (total number of long words to transfer), 

Drive !BRQ~(Futurebus+ Bus ReQuest) to Futurebust Arbitration Controller. 


BGRNT~ (Bus GRaNT) from 
Futurebus* Arbitration Controller? 


Drive !BR_FB~ (Bus Request for Futurebus# DRAM Access) to Local Bus Arbitor, 
Turn Futurebus+ Address/Data Transceivers to Transmit (! WRITE~), 4 
Enable Masters Address, Command, and Capabllity to Futurebus+ Transceiver (! EN_M_FA~, 1 EN_M_CC~) 


PARALLEL » EVENTS — 


20 ns delay from ! BGRNT~ - 
!BG_FB~ (Local Bus Grant for 


Futurebust DRAM access)? 


Clock Masters Address, Command and Capability (co, Compelled) 
onto Futurebus+ [M_S_CKO, AD (32:0), CM (7:0), CA1] 
Drive input Address, Data, Status,Command and 
Capability Latches to Fall-thru (M_S_LEI) : Enable Local Address Counter to 
: _ | DRAM controller address Inputs 
- (VENLM-LAS) 


30ns delay from I BGRNT~ : 
es 30ns delay from ! BG_FB~ 


Drive AS, 
Disable Masters Address to Futurebust Drive AREQ~ (Access REQuest) to 
transcelvers (EN_M_FA~) DRAM Controller 





BOTH EVENTS COMPLETED . 


_NO YES 
. Access? . . 
MASTER WRITE: MASTER. READ: - 


Read Access from Slave Board: ; Write Access to Slave Board: 
Connection Phase Part 2 ~ _* Connection Phase Part 2 


nails gt TL/F/11155-2 
FIGURE 2a. Master Connection Phase: Part 1, Flow Chart — 
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September 25, 1990 


MASTER WRITE: -MASTER READ: 
Read Access from Slave Board, _ Write Access to Slave Board, 
CONTINUED CONTINUED 


i tal (f) & VAI(f) & 0 (f) & 


DI (f)? 1 ADD_ACK~? 


YES YES 


Turn Futurebus# Address/Data Transceivers to Recelve (WRITE~) Drive DT_STB to request Data from DRAM 


10ns delay from !Al(f) and DI(f) 10ns delay from (!ADD_ACK~ & ! Al(f) & DI(f)) 


. }Latch input Status and Capability (1 M_S_LEI) Latch Input Status and Capability (1 M_S_LEI) 


Any Status Errors? Any Status Errors? 
(WT, BE, ISL, BS, SR) (WT, BE, !SL, BS, SR) 


GO TO 
DISCONNECTION 
PHASE 


Are Status bits IV Ara Status bits IV 
or BC asserted? or BC asserted? 


Look at filtered versions of-DK and Di, DK(f), DI(f) . ; [Look at filtered versions of DK and DI, DK(f), DI (f) 
and set Command (sw) if IV Status received ‘and set Command (sw) if IV Status recelved 


Clock Command and Capability (co) 
out to Futurebus+ for first data access 
" [M_S_CKO, CM (7:0)] 

Clock Command, Capabllity (co) and Data out to Futurebust 
for first data access [M_S_CKO, AD(31:0), CM (7:0)], 





Drive !DT_STB to request next piece of Data from 
the DRAM 


10ns delay from D_ACK and 
20ns delay from! Al(f)) 20ns delay from(!ADD_ACK~ & 1AI(f)) 


GO TO: . . GO TO: 
MASTER WRITE: MASTER READ: 
Read Access from Slave Board: Write Access to Slave Board: 
ODD BEAT DATA PHASE ODD BEAT DATA PHASE 


FIGURE 2b. Master Connection Phase: Part 2, Flow Chart 


TL/F/11155-3 
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Date ... December 12, 1990 






Master Write: Read access from Slave, 
Continued from Connection Phase or 
Even Data Beat 






Drive DS and M_S_LEI 


i, ae & 
IADD_ACK~ & 


: !D_ACK? 







YES 


Latch input Data, Status and Capabllity In Futurebus+ 
_ Transceiver (! M_S_LEI) 
Drive DT_STB to Write the Slave Data to the DRAM 


10ns ‘delay from !DI(f) 


Any Status Errors? 
(ED, BE) 









Last Transfer from Master 
(LAST_XFER)? 





YES 


GO TO: 
MASTER WRITE: 
Read Access from Slave Board: 
EVEN BEAT DATA PHASE 








10ns dela 
from !DI ( 


DISCONNECTION 





Master Read: Write access to Slave, 
Continued from Connection Phase or 
Even Data Beat 





Drive DS and M_S_LEI 
. | YES 
Latch input Status and Capability in Futurebust 
Transceiver (! M_S_LEI) 


PARALLEL » EVENTS 









Clock Command, Capability (co), and 
Data out to Futurebus+ 
[M_S_CKO, AD (31:0), CM(7:0)], 
Drive DT_STB to request the next 
plece of data from the DRAM 


BOTH EVENTS COMPLETED 




















Any Status Errors? 











Last Transfer from Master 
(LAST_XFER)? 


NO 


10ns delay from(ID_ACK & !DI(f)) 


GO TO: 
MASTER READ: 


- Write Access to Slave Board: 


EVEN BEAT DATA PHASE 


TL/F/11155=4 


FIGURE 2c. Master Odd Data Beat: Flow Chart 








Date ... December 12, 1990 


Master Write: Read access from Slave, 
Continued from Even Data Beat 


Drive !DS and M_S_LEI 


oe 1DK(f) & 


D_ACK? 





Latch input Data, Status and Capability In Futurebus+ 
Transceiver (! M_S_LEl) 
Drive | DT_STB to Write the Slave Data to the DRAM 


10ns delay from ! DK (f) 


Any Status Errors? 
(ED, BE) 


LSZ-NV 


Master Read: Write access to Slave, 
Continued from Even Data Beat 


Drive IDS and M_S_LE! 


YES 
Latch input Status and Capability in Futurebus+ 
Transceiver (!M_S_LEl) 


PARALLEL y EVENTS 


10ns delay 


from 10K (f) Clock Command, Capability (co), and 


Data out to Futurebus+ 
[M_S_CKO, AD (31:0), CM (7:0)], 
Drive |DT_STB to request the next 
plece of data from the DRAM 


BOTH EVENTS COMPLETED 


. Any Status Errors? 
ED, BE 


GO TO 


DISCONNECTION 


Last Transfer from Master 
(LAST_XFER)? 


GO TO: 
MASTER WRITE: 
Read Access from Slave Board: 
ODD BEAT DATA PHASE 


PHASE 


Last Transfer from Master 
(LAST_XFER)? 


NO 


10ns delay from(D_ACK & !DK(f)) 


GO TO: 
MASTER READ: 
Write Access to Slave Board: 
ODD BEAT DATA PHASE 


TL/F/11155-5 


FIGURE 2d. Master Even Data Beat: Flow Chart 
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Date ... December 12, 1990 


From Master Connection Phase, Odd 
Data Beat or Even Data Beat 


Clock Command and Capability (co) out to Futurebust 
[M_S_CKO, CM97:0)], 
Turn Futurebus# Address Data Transcelvers to 
Receive (WRITE~), 
Disable Masters Data, Command, and Capability to 
the Futurebus+ Transcelvers (EN_M_CC~), 

Take appropriate action of the DISCONNECTION 
phase was entered because of an error condition, 
If no more transfers to perform, Negate BRQ~ (Bus 

ReQuest) to the Arbitration Controller (i BR_FB~) 


10ns delay from | DISCONNECT~ 


Drive 1!AS to terminate this Futurebust transaction 
Drive AREQA. to terminate DRAM accessing 


10ns delay from !AK(f) 


Any vo le iS Take appropriate system action 


Drive !ENDT~ 
Drive Data, Status, and Capability latches 
; to fallethru (M_S_LEI) 


Drive DISCONNECT~ 
Drive ENDT~ 
Drive AREQ_ to terminate DRAM accessing 


Participate in Futurebus+ 
Transactions as a Master, Slave, 

or Non=Selected Module TL/F/11155-6 
FIGURE 2e. Master Disconnection Phase: Flow Chart 
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Pi-Bus Overview 


Dan Mansur 


Pl-Bus, Parallel Interface Bus, has evolved over the late 
1980’s to become the backplane of choice for avionics ap- 
plications. National Semiconductor has utilized its BTL ex- 
perience and supports the Pl-Bus standard by offering a 
BiCMOS Octal PI-Bus transceiver. 


Pl-Bus Standard 


The Pl-Bus standard initially was developed under the Very 
High Speed Integrated Circuits (VHSIC) program, a program 
that funds development of advanced semiconductor tech- 
nology for military use. In an effort to reduce redundant de- 
velopment of avionics subsystems, the U.S. Congress man- 
dated that certain new aircraft programs will need to coordi- 
nate technology requirements. To this end, the Joint Inte- 
grated Avionics Working Group (JIAWG) was created of 
armed service and industry representatives to coordinate 
and standardize duplicative efforts. 


The principle output of JIAWG regarding hardware was the 
creation of a common modular avionics architecture that 
could be configured to any aircraft. Known as the Advanced 
Avionics Architecture, it prescribes a bus oriented approach 
using various combinations of modules to achieve the differ- 
ent avionic needs. The current version of this architecture is 
known as Common Avionics Baseline III (CAB Ill) and is 


also incorporated in the Society of Automotive Engineers’ » 


(SAE) specifications. Development is also underway within 
Aeronautical Radio, Inc. (ARINC) to make Pl-Bus the stan- 
dard avionics backplane for commercial aircraft. 


This architecture addresses those functions which could be 
implemented with common hardware and common comput- 
er programs to allow adaptation to either air-to-air or air-to- 
ground missions. The architecture features a building-block 
design, using standardized modules that can be plugged 


into a rack and linked by high speed data busses. Instead of © 


line-replaceable units, the new approach features line-re- 
placeable modules or, as they are now called, common 
modules. © , 


Applications for the Pl-Bus systems include flight control, 
communications, target acquisitions, weapon delivery, bat- 
tlefield management, navigation, electronic countermea- 
sures, stores management and radar management. Specific 
mandated programs include the U.S. Navy Advanced Tacti- 
cal Aircraft (ATA), the U.S. Air Force Advanced Tactical 
Fighter (ATF), the U.S. Army Light Helicopter Experiment 
(LHX). Several existing airframes, such as the F-15 or the 
F-16, will be retrofitted. In addition, Pl-Bus systems are ex- 
pected to rapidly migrate into the commercial avionics as 
well. 


PI-Bus Backplane Features 


The Pl-Bus backplane is a_linear, multidrop synchronous 
bus with supports digital message communications between 
up to 32 modules residing in a single backplane. Messages 
are transferred datum serial and bit parallel using data size 
of 16 bits (single word) or 32 bits (double word). 

Pl-Bus standard uses a master-slave communications pro- 
tocol which allows the current bus master to read data from 
one slave or write data to any number of slaves in a single 
message sequence. Messages may be routed to a particu- 
lar module using either logical or physical addressing. A 
number of independent messages may be transmitted dur- 
ing a bus master’s tenure. This message formats provide a 
32-bit virtual addressing range for each module. 


The Pl-Bus protocol specifies a set of bus state transitions . 


which control the bus to operate in a pipeline manner at the 
maximum clock rate allowed by the bus signal propagation 
delay. Master-Slave handshaking is provided with minimum 
performance penalty by operating the slave modules in syn- 


chronization with, the master and using the bus state look- 


ahead. 


National’s Pl-Bus Transceiver 


National’s octal Pl-Bus transceiver was designed to meet 
the low power requirements of the military by combining the 
company’s leading BTL (Backplane Transceiver Logic) with 
an advanced BiCMOS process. 


BTL transceivers feature a nominal 1V signal swing for low 
power consumption, with receivers having precise thresh- 
olds for maximum noise immunity, and drivers with low pow- 
er capacitance to minimize bus loading. These features 
combine to allow higher bus-data-transfer rates and im- 
proved overall system reliability. They also eliminate per- 
formance-degrating settling-time delays. 


National’s patented design and BiCMOS process enable 
the DS1776 to operate at approximately one-fourth the 
power of competing devices. The reduced power consump- 
tion is reflected in the worst-case current (Icc) requirement 
of only 37 mA for the DS1776, compared with 145 mA for 
competing devices. This low power solution can offer up to 
1 Amp per board savings, reducing the concerns of avionics 
manufacturers regarding excessive power consumption in 


the limited space available. 
} 


' 
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HISTORY 


Throughout the 70’s and early 80’s the typical backplane 
was driven by standard TTL logic parts with tristateable out- 
puts such as 54/74XX240 and 245. For design purposes 
these busses were modeled as lumped capacitances and 
transmission line effects were ignored because the bus data 
rates were generally not fast enough to require designers to 


be concerned with transmission line effects of the back-_ 
plane. With the lower bus speeds there was sufficient bus 
settling time for reflections to dampen, and the signals to 


stabilize close enough to steady state to avoid problems. If 
a bus was heavily loaded and attempts were made to run 


the bus faster than 10 MHz, errors in data were frequently 


seen due to line reflections causing line voltage levels to 
transition through threshold more than once for a single 
transition of the buffer input.-And as backplane densities 
increased, loading from the transceivers became so great 
that this increased the’ poem of oe the bus mulchy 
and error free. ; 


With today’s higher bus data rates it has become imperative 


that the transmission line characteristics of the backplane - 


be accounted for in backplane analysis. By doing so it be- 
comes apparent that there may be better ways to drive 
backplanes than with traditional TTL family logic. 

To solve some of the inherent problems with running dense- 
ly loaded busses, the P! Bus structure was developed. Pi 
Bus (parallel interface bus) was developed by IBM, Unisys 


and TRW for the VHSIC 2.2 Interoperability program. PI Bus - 


has since been adopted by the Joint Integrated Avionics 
Working Group (JIAWG) section of SAE. 


TRANSMISSION LINE PHYSICS — 


Several problems must be overcome to run a faster, more 
heavily loaded bus. When the bus propagation delay plus 
settling time decreases below about 100 ns the backplane 
must be considered as a transmission line. If the backplane 
is densely populated the problem of running it at high data 
rates is exacerbated. 


Zo is the characteristic impedance of the backplane, and is 


calculated from the physical characteristics of the back- 
plane. From Figure 7, a simple model of a transmission line, 
the following equation may be written: 


Zo= ((R-+ jw) / (G+ jwe) ]’2 
For high frequency, the R and G terms become insignificant 
due to the increases in the w terms, 
w = 2 af where fis frequency 

and the equation simplifies to 

Zo = (L/C)'" 
where L is in units of inductance per unit length and C is in 
units of capacitance per unit length 


L R 


TL/F/11071-1 
FIGURE. 1 
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EFFECTS OF CAPACITIVE LOADING ON BUS 


Values for Zp can be calculated from the physics of the 
backplane construction. For a typical Pl Bus epoxy-glass 
backplane the value for Zo is about 652. The basic equation 
describing the impedance of a loaded bus is 
= Zo/ (1 + C1/C)% 

where C; is the additional load added to the bus by mod- 
ules, connectors and connector mounting vias. So as the 
capacitive load of the modules increases, the impedance of 
the bus decreases. As the impedance of the bus decreases, 
the current required to drive the bus between state changes 
in a given time period increases (! = V/Z). The equation for 
the propagation delay of a signal on an unloaded transmis- 
sion line is 


Tpp = £(L/C)% 
= length of the bus. 


where 2 
For a loaded bus, 

Tpy = Tpo/(1.+ C4/C)% , 
describes the propagation delay on a transmission line. 
From the equation for the loaded bus, it is obvious that as 
the capacitive loading of the bus increases, the propagation 
delay for a given length of bus increases. As this time in- 
creases bus settling time increases, and hence affects how 
fast the bus may be operated. So a bus transceiver which 
had low capacitive loading would improve bus operation in 
several ways. A low capacitive transceiver would raise the 
value of Z;, and hence the drive current requirements for a 
given performance would be reduced, the propagation delay 
for a given length of backplane would be reduced, and any 
bus settling time required would also be reduced. 


OUTPUT Vox SWING 


The standard TTL swing for an output i is from 0.2V to Vcc — 
two diodes (for CMOS OV to Vgs). For a bipolar device, this 
swing could be as much as from 0.2V to 4.1V. The smaller 
this swing between high and low, the less charge which 
must be moved in any given time to effect a change of state. 
So from the standpoint of power usage, smaller j in this case 
would be better. 


PI Bus developed as a bus to address both these conclu- 


_ sions in a manner similar to Future Bus. The bus side out- 
_ puts are open Schottkys, and the bus is terminated on both 


ends by a resistor to a voltage source with limits of 1.9V to 
2.1V (Figure 2). The resistors used to terminate the bus may 


_ be from 302 to 40N. By terminating the bus in this way, (Zo 


matches 402 termination with no loads on the bus, but in- 


. cluding loading from raw backplane plus vias and mating. 


connectors, and a 302 termination matches a fully loaded 
PI bus backplane) the bus is somewhat tuned to the Z, of. 
the bus so that reflections can be minimized. By terminating 
the bus to a maximum of 2.1V, the maximum voltage swing 
on the bus will be from the Vo, minimum spec of 0.4V to the 
maximum 2.1V. Thus the voltage swing for the PI Bus trans- 
ceiver would be 1.7V versus the 3.9V for a standard bipolar 
transceiver. 








TL/F/11071-2 


FIGURE 2 


OUTPUT CAPACITANCE OF TRANSCEIVER 


In order to decrease the capacitive loading of each trans- 
ceiver, Schottky diode outputs are used, and are reverse 
biased when not active low. The PI Bus driver output is 
shown in Figure 3a. When the output is in a high state both 
the output Schottky diode and the collector-substrate diode 
of Q1 are. reverse biased. By reverse biasing both the 
Schottky diode junction and the collector-substrate junction 
the parasitic capacitive loading of the bus driving output can 
be greatly decreased. The following equation gives an ap- 
proximation of the impact reverse biasing has upon junction 
capacitance: 
Cj = Cjo/(1 +. Va/Vo)'2 

where Cj equals the capacitance of the diode junction un- 
der unbiased conditions, and Vg equals the reverse biased 
voltage of the diode junction. Vo is the built-in zero bias 
potential across a diode junction, and would be on the order 


OUTPUT 


ee ae TL/F/11071-3 
| Simplified Circuit 


OUTPUT 





it 


TL/F/11071-4 
b. Parasitic Capacitance 
FIGURE 3 


of 0.7V. So, by reverse biasing the cathode of both D1 and 
Qi, their parasitic capacitive loading on the bus is de- 
creased. If the bus were.at 2.0V, and Vcc was at 5V, Cjo 
would be decreased by a factor of 2.1. Then of course, C1 
and C2 are in series, so their total capacitance would be 
decreased according to the following equation: 


Cr = Cp + [(C4) (C2 + Cg)] + (Cy + Cg + Co) 
The capacitance of C3 (from D3) is basically negligible in 
comparison to C1 because it is approximately 0.5% the 


area Q1. The package capacitance (Cp) may vary from 


0.3 pF to 1.5 pF, depending upon the package and the pin 
location on the package. The other capacitive loading on 
each bus pin would be the base-collector and base-emitter 


TL/F/11071-5 


TL/F/11071-6 


FIGURE 4 
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capacitance of Q7 (Figure 5b), which connects to the anode 
of D1. For a typical TTL part (Figure 4), the capacitive load- 
ing of the output would be primarily C5 because C6 is in 
series with C7 and the parallel combination of C8 and C9. 
For Q4 and Q5 being about the same size devices, the ca- 
pacitive loading of the TTL circuit would be several times 
larger than that of the Schottky terminated circuit. 


PRECISION THRESHOLD 


In order to handle the smaller output swing on the bus, it is 
necessary to use a more precise threshold circuit on the bus 
receiver input. Figure 5a is a typical TTL input buffer. The 
threshold set by this type of circuit varies considerably with 
temperature, and typically ranges from about 1V at high 
temperatures to about 1.8V at low temperatures. Such 
movement could not be tolerated with a bus swing which 
could be as small as from 1.15V.to 1.9V. The circuit shown 
in Figure 5b is used on PI! Bus transceivers to set a more 


precise threshold. A voltage reference with a very small Vcc | | 


and temperature dependence is placed on the chip to es- 
tablish a precision threshold for the P! Bus to BIU input buff- 
er. By using a differential pair with one of the pair controlled 
by the reference voltage, the threshold can be maintained 
within a 150 mV window centered at 1.52V. : 


OUTPUT RAMPS AND NOISE IMMUNITY 


Ramped outputs have been touted as the solution to prob- 
lems of bus reflections and crosstalk. The amount of ramp 
time put into rise and fall times directly related to the propa- 


gation delays of a transceiver, so longer ramps require long- 


er delay times. An important question to ask is how much of 
a ramp buys what degree of decreased bus settling time. 
Many TTL parts have peak ramps of about 2V/ns. This rate 
of ramp certainly seems to increase bus settling times. The 
P! Bus transceiver will have a typical ramp rate of about 
0.5V/ns. 


Having some amount of noise rejection on the bus receiver 
input allows the bus buffer input to ignore small excursions 
above or below threshold without affecting the data being 
transmitted to the BIU. However the greater the amount of 
noise immunity, the greater the propagation delay on the 
path from the bus to the BIU. The PI Bus transceiver offers 
a compromise between noise immunity and prop delays with 
typically 4 ns of pulsewidth protection measured at 1.5V for 
a1 to 2 volt input. 


INTERNAL 
SIGNAL 


TL/F/11071-7 
a. Typical TTL Input 


SUBMICRON BIU PROTECTION 

To accommodate future submicron BIU processing, the Pl 
Bus transceivers offer a feature for limiting the output Voy 
excursion to the BIU. The Vx pin on the chip can be used as 


-aclamp voltage to limit the Voy of the BIU side output. The 


basic propagation delays on the transceiver with the excep- 
tion of the BIU side low to high ramp rate are unaffected 
because the remainder of the transceiver is still powered by 
the normal Vcc pin. Only the BIU Voy is controlled by the 
Vx pin. The Figure 6 schematic shows how the Vx voltage 
sets the output Vox. 


TL/F/11071-9 


FIGURE 6 - 


INTERNAL 
REFERENCE 
VOLTAGE 


TL/F/11071-8 
b. P| Bus Receiver Input 


FIGURE 5 








LOW POWER 


Many applications of Pl Bus are designed with a redundant 
bus, and as such always have a full set of transceivers in 
the inactive mode. And in addition, on the active bus there 
may be 15 inactive (for a 16 drop bus) transceivers with one 
active transceiver. So in order to lower the power require- 
ments for the P! Bus backplane application the National Pl 
Bus transceiver, the DS1776, was designed using BiCMOS 
in order to take advantage of the power savings possible 
with the use of CMOS in appropriate portions of the circuit. 


A pure bipolar transceiver would have an Icc inactive speci- 
fication of about 100 mA. By using a BiCMOS process it was 
possible to design a PI Bus transceiver with an Icc inactive 
of 35 mA. 


BIPOLAR vs CMOS vs BICMOS TECHNOLOGY 


A full bipolar transceiver could be built to provide excellent 
performance in most areas with the exception of power con- 
sumption in both the active and inactive modes. A pure 
CMOS part could be designed with a much lower Ic, but it 
would have the following drawbacks, It would be slower 
than a bipolar part, no Schottky diode would be available to 
construct a low capacitance output with limited swing, and 
stable CMOS voltage references which have a reasonable 
silicon area are non-existent, so setting a precise input volt- 
age threshold would be difficult. 


By making judicious use of bipolar and CMOS circuits where 
each is appropriate, it was possible to design a PI Bus trans- 
ceiver with an Icc inactive of typically 35 mA and yet main- 
tain the full features which make PI Bus a clean and quiet 
bus to run. 
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GA National 


Semiconductor — 
DS1776 Pl-Bus Transceiver 


General Description | 


The DS1776 is an octal Pl-bus Transceiver. The A to B path 
is latched. B outputs are open collector with series Schottky 
diode, ensuring minimum ‘B ‘output loading. B outputs also 
ave ramped rise and fall times (2.5 ns typical), ensuring 
minimum Pl-bus ringing. B inputs, have glitch rejection cir- 
cuitry, 4 ns typical. 
Designed using National’s Bi-CMOS process for both low 
operating and disabled power. AC performance is optimized 
for the Pl-Bus inter-operability requirements. 


The DS1776 is an octal latched transceiver and is intended 
to provide the electrical interface to a high performance 
wired-or bus. This bus has a loaded characteristic imped- 
ance range of 209 to 500 and is terminated on each end 
with a 302 to 4002 resistor. 


The DS1776 is an octal bidirectional transceiver with open 
collector B and TRI-STATE® A port output drivers. A latch 


Pin Configurations 


Pin Configuration 
2oG 


43 2 


oon PO He WwW HS 


TL/F/10875~1 


Pin Configuration CLCC 
8g es 


ot oO > 


1 28 27 26 


28 CLCC 


PRELIMINARY 


function is provided for the A port signals. The B port output 
driver is designed to sink 100 mA from 2V and features a 
controlled linear ramp to minimize crosstalk and ringing on 
the bus. 

A separate high level control voltage (Vx) is provided to 
prevent the A side output high level from exceeding future 
high density processor supply voltage levels. For 5V- ye: 
tems, Vx is tied to Vcc. 


Features 

@ Mil-Std-883C qualified 

m Low power Ico, = 37 mA max 

m B output controlled ramp rate . 

@ B input noise immunity, typically 4 ns 

a Available in 28-pin DIP, Flatpak and CLCC 
@ Pin and function compatible with Signetics 54F776 


Logic Symbol 
3.5 6 7 9 10 12 13 


AO Al A2 A3 A4 AS AG A7 


BO B1 B2 B3 B4 BS B6 B7 
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Order Number DS1776E/883, DS1776J/883 or DS1776W/883 
See NS Package E28A, J28B or W28B 








DEVICE SPECIFICATIONS 
Absolute Maximum Ratings (notes 1 and 2) 


If Military/Aerospace specified devices are required, Storage Temperature Range (Tstc) —65°C to + 150°C 
please contact the National Semiconductor Sales Lead Temperature (Soldering 10 Sec.) 260°C 


Office/Distributors for availability and specifications. ESD Tolerance: 


Supply Voltage (Vcc) —0.5V to +7.0V Czap = 120 pF, Rzap = 15000 2.0 kV 


Vx, Von Output Level Control Voltage 


(A Outputs) = 0.5V to +7.0V Operating Conditions 


OEBn, OEA, LE Input Voltage (V)) —0.5V to +7.0V 
A0-A7, BO-B7 Input Voltage (Vi) —0.5V to +5.5V Supply Voltage (Vcc) 


Min Max Units 
4.5 5.5 V 


Input Current (I) —40 mAto +5 mA Operating Temp.Range(Ta)  -55 +125 °C 
Voltage Applied to Output in Input Rise or Fall Times (t,, tp) 50 _ ns 


High Output State (Vo) —0.5V + VocV 
A0-A7 Current Applied to Output 

in High Output State (Io) 40 mA 
BO-B7 Current Applied to Output 

in High Output State (Io) 200 mA 


DC Electrical Characteristics voc = 5v +10% (Unless Otherwise Specified) 


Parameter Conditions (Note 3) Limits —55°C to + 125°C 
. Typ (Note 4) 


High Level Input Voltage 
OEBO, 1, OEA, LE, An 
Bn 


Low Level Input Voltage 
Except BO-B7 
BO-B7 (Note 5) 


High Level Output Current Vin = Vin or Vi 

A0-A7 VoH = Vcc — 2.0V 
High Level Output Current Voc = Max, Vi_ = 0.8V, 
BO-B7 Vin = 2.0V, Von = 2.1V 


Low Level Output Current Vin = Vin or Vit 
AO-A7. VoL = 0.5V 
BO-B7 Vor = 1.15V 


Input Clamp Current 
Except AO-A7 
A0-A7 


TRI-STATE Output Leakage Current 

A0-A7 

BO-B7 
Note 1: Absolute Maximum Ratings are those values beyond which damage to the device may occur. 
Note 2: Unless otherwise specified all voltages are referenced to ground. 


Note 3; For conditions shown as Min or Max, use the appropriate value specified under recommended operating conditions for the applicable type and function 


table for operating mode. Unless otherwise specified, Vx = Vcc for all test conditions. 
Note 4: All typical values are at Voc = 5V, Ta = 25°C. 


Guaranteed 


20 
100 


zg 
0.8 


I 4 
hoa 
Oo @ 


H 
~ 
oO 


Note 5: Due to test equipment limitations, actual test conditions are for Vjy = 1.9V and for Vi_ = 1.2V, however the specified test limits and conditions are 


guaranteed. 
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DC Electrical Characteristics voc = 5v +10% (Unless Otherwise Specified) (Continued) 


Guaranteed 
Parameter : Conditions Limits —55°C to + 125°C | Units 


High Level - |AQ-A7 Voc = Min, Vit = Max,}loy = —3 mA, Vx = Voc 
Output Voltage Vin = Min 


lon = —0.4 mA, 
Vx = 3.13V & 3.47V 


Low Level A0-A7 Voc = Min, Vit = Max,}lo. = 20 mA, Vx = Voc 
Output Voltage Vin = Min * 
BO-B7 Voc = Min, Vi, = Max,/lo. = 100 mA 
Vin = Min lo. = 4mA 


= 


ook 


BO-B7 Voc = Max, V; = 5.5V 


Input Current Voc = Max, Vj = 2.1V 
Low Level Voc = Max, Vi = 0.5V 
Input Current Voc = Max, V) = 0.3V 


TRI-STATE Output | AO-A7 Voc = Max, Vo = 2.7V 
Current, High Level 
Voltage Applied 


TRI-STATE Output | AO-A7 Voc = Max, Vo = 0.5V 
Current, Low Level 
Voltage Applied 


High Level Control Current ~ Voc = Max, Vx = Voc, 
LE = OFA = OEBn = 2.7V 
A0~-A7 = 2.7V, BO-B7 = 2.0V 
Voc = Max, Vx = 3.13V & 3.47V, 
LE = OEA = 2.7V, 
OEBn = A0-A7 = 2.7V, BO-B7 = 2.0V 


los Short-Circuit Output} AO-A7 Only |Vcoc = Max, Bn = 1.6V, 
Current (Note 6) OEA = 2.0V, OEBn = 2.7V 
_ |Supply Current IocH Voc = Max (Note 7) 
(Total) IocL Voc = Max, Vi; = 0.5V 
locz Voc = Max, Vi; = 0.5V 
loFF Power Off BO-B7 Bn = 2.1V, Voc = 0.0V, 
Output Current Vit = Max, Viq = Min 
Note 6: Not more than one output should be shorted at a time. For testing Iog, the use of high speed test apparatus and/or sample-and-hold techniques are 
preferable in order to minimize interna! heating and more accurately reflect operational values. Otherwise, prolonged shorting of a High output may raise the chip 


temperature well above the normal and thereby cause invalid readings in other parameter tests. In any squence of parameter test, log tests should be performed 
last. : ; 


Note 7: 8 inputs @ Voc. 
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AC Electrical Characteristics ‘ 


Path Test Conditions| min | Typ | Max | units 


BTOAPATH , 


Propagation Delay B toA Waveform 1, 2 
Output Enable OEA to A Waveform 3, 4 
Output Disable OEA toA Waveform 3, 4 


ATOB PATH 


9ZZLSG 


Propagation Delay A to B Waveform 1, 2 


Propagation Delay LE to B Waveform 1, 2 
Enable/Disable OEBn to B Waveform 1, 2 
Transition B Side 
1.2V to 1.8V, 1.8V to 1.2V 


SETUP/HOLD/PULSE WIDTH SPECS 


Waveform 5 
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DS1776 


Description 
PIN DESCRIPTION 


Symbol 


_ AO 
Al 
A2 

_ AS 
A4 
A5 

. AG 

_ AT 

BO 
BI 
B2 
B3 
B4 
B5 
B6 
B7 

OEBO 

OEB1 


tE 


Vx 


| pins | Type | 
ee a ee 
ee See ee 
ee 
a 
aia, | vo 
ee ee 

1/0 

/0 

/0 

/0 

1/0 


Ie 
Ie 
eee Dee 
pense ee 
a ae 


TABLE I. Pin Description 


Name and Function .- 


PNP latched input/TRI-STATE output (with Vx control option) 


Data input with special threshold circuitry to reject noise/Open Collector 


output, High current drive 


Enables the B outputs when both pins are low 


Enables the A outputs when High 


Latched when High (a special delay feature is built in for proper enabling 
times) 


Clamping voltage keeping Vox from rising above Vx (Vx = Vcc for normal 
use) 
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DS1776 


TL/F/10875~4 


= nN ” ~ Ys] 
a a a a a 
© a ” = o 
N NN NN N nN 


a A a a a e A Z| 
1s ete ee ee ed ee ot eel] 
RSS (ESR) (See (ad (Pee i ee a ee es ee ed Vee 


an IMIDE) 


FIGURE 1. Functional Logic Diagram — 





iption (Continued) 


Descr 

FUNCTION DESCRIPTION 
Voc = Pin 1 

Vx = Pin 14 

GND = Pins 4, 8, 11, 18, 22, 25 








DS1776 


Description (continued) 


TABLE II. Function Table 


Latch 
State 


Inputs 


Bn (Note 3) 
X 


OEB 


rc 


H (Note 2) - 


cricietef[ef{[eje|™ 
_ ° 


De ae a Se eo Se Bene fe Se eS Oe Oe De Oe 


= 


= 
SiC yc yLo yo Il KEK EK KL KIX 


Poe 
pede 


H = High Voltage Level 

L = Low Voltage Level 

X = Don’t Care 

— = Input not externally driven 

Z = High impedance (off) state : 


Mode 


A TRI-STATE, Data from A to B 


A TRI-STATE, Latched Data to B 
Feedback: Ato B, BtoA 


Preconditioned Latch Enabling 
Data Transfer from B toA 


(Note 1) 
off (Note 2) 
off (Note 2) 


Latch State to A andB 
off 

off B off and A TRI-STATE 
off 


B off, Data from B toA 
off 
Off 
off B off and A TRI-STATE 
ff 
ff 


B off, Data from BtoA 


Qn = High or Low voltage level one setup time prior to the Low-to-High LE transition 


Note 1: Condition will cause a feedback loop path; A to B and B to A. 
Note 2: The latch must be preconditioned such that B inputs may assume a High or 


Low level while OEBO and OEB1, are Low and [Eis high. 


Note 3: Precaution should be taken to ensure that the B inputs do not float. If they do, they are equal to a Low state. 


off = Applies to “‘B” (OC) outputs only. Indicates that the outputs are turned off. 


CONTROLLER POWER SEQUENCING OPERATION 


The DS1776 has a design feature which controls the output 
transitions during power up (or down). There are two possi- 
ble conditions that occur. 


1. When LE = Low and OEBn = Low, the B outputs are 
disabled until the CE circuit can take control. This feature 


Switching Characteristics 
AC WAVEFORMS 


An, Bn, OEBn, LE 1.5V 1.5V 
tPLH teHL. 
OH 
An,Bn 1.5V 1.5V 
OL 


TL/F/10875-5 
Waveform 1: Propagation Delay for Data to Output 


ensures that the B outputs will follow the A inputs and 
allow only one transition during power up (or down). 


2.!f LE = High or OEBn = High, then the B outputs still 
remain disabled during power up (or down). 


OEBn , LE 5V 1.5V 


teHL teLH 
An, Bn 1.5¥ 1.5¥ 


Vor 
TL/F/10875-6 
Waveform 2: Propagation Delay for Data to Output 





Switching Characteristics (Continued) 
AC WAVEFORMS (Continued) 


9ZZ1SG 


OEA 1.5V 1.5V 


tezy teyz 
Voy = 0.3V 
‘OH 
An 1.5V 
0.0V 


TL/F/10875-7 
Waveform 3: TRI-STATE Output Enable Time 
to High Level and Output Disable 
Time from High Level 


Voy + 0.3V 


TL/F/10875-8 
Waveform 4: TRI-STATE Output Enable Time 
to Low Level and Output Disable 
Time from Low Level 


TL/F/10875-9 
Waveform 5: Data Setup and Hold Times and LE Pulse Widths 
The shaded areas indicate when the input is permitted to change for predictable output performance. 


TEST CIRCUIT AND WAVEFORMS 
Test Circuit for TRI-STATE Outputs on A Side 


Voc 





PULSE 
GENERATOR 


Switch Position 


| Test _| switch | 





tpiz, tpz_ | Closed 
All Other Open 


Test Circuit for TRI-STATE Outputs on B Side 


Voc 


PULSE 
GENERATOR 


(Includes jig 
capacitors) 
TL/F/10875-12 
DEFINITIONS 
R,_ = Load resistor 5002 
C,, = Load capacitance includes jig and probe capacitance 
Rr = Termination resistance should be equal to Zour of pulse generators. 
Ry = Pull up resistor 


(Includes fig 


capacitors, 
7 ) TL/F/10875-10 


Input Pulse Definition 
ty AMP (V) 


LOW V 
triy(t,) 


tri (Vv) 


LOW V 
TL/F/10875-11 


|Amplitude|Low V|Rep.Rate| tw _|tris| tri 


Aside] 3.0v_| oov | 1MHz_|500ns| 2ns| 2ns| 
Bside] 20v_| 1.0v | 1MHz_|500ns| ans] 2ns| 
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ZA National 


Semiconductor 


Futurebus + /BTL Reference 


Futurebus+ /BTL Modeling 
Support 


National Semiconductor, in an effort to assist system de- 
signers with board level design and simulation, has made 
available a series of spice and behavioral level models for 
its Futurebus + /BTL devices. 


SPICE MODELING SUPPORT 


BTL Spice Modeling Manual 
BTL/Futurebus+ Spice Models 

BTL Turbo Transceiver Spice Models 

BTL Trapezoidal Transceiver Spice Models 


Behavioral Model Support: (All are Verilog Models) 
DS3883 9-Bit BTL Data Transceiver 

DS3884 6-Bit BTL Handshake Transceiver 

DS3885 Arbitration Transceiver 

DS3886 9-Bit BTL Latched Data Transceiver 
DS3875 Arbitration Controller 


Wire Wrap Boards with NSC’s 
Futurebus+ Chipset 


Presently, wire-wrap boards with NSC’s Futurebus-+ chip- 
set are being offered by two companies, Mupac and Hybri- 
con. 


These boards have National's Futurebus+ transceivers 
surface mounted for optimum stub length and signal integri- 
ty. The wire-wrap option enable designers to implement and 
test different levels of the Futurebus+ specification in an 
actual Futurebus+ system. 


These products offer a system designer a time-to-market 
advantage as_ transceiver/connector/board/backplane 
electrical evaulation can be completed while actual board 
design is in progress. A user can complete electrical signal 
characterization and noise budget analysis, without having 
to wait for fabricated prototype boards. Full evaluation on 
NSC’s BTL transceivers and technology is now made one 
step easier for the end user. 
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Futurebus+ /BTL Reference 


Futurebus+ Backplane 
Manufacturers 


Augat 

33 Perry Avenue/P.O. Box 779 
Attleboro, MA 02703 

(508) 222-2202 


BICC-VERO Electronics, Inc. 
1000 Sherman Avenue 
Hamden, CT 06514-1336 
(203) 288-8001 


Hybricon Corporation ; 
12 Willow Road/P.O. Box 149 . 
Ayer, MA 01432 
(508) 772-5422 


Mupac Corporation 
410 Mupac Drive 
Brockton, MA 02401 
(508) 588-6110 


Schroff, Inc. 

170. Commerce Drive 
Warwick, RI 02866 
(401) 732-3770 


Futurebus+ 2mm Connector | 
Manufacturers © 


DuPont Electronics 
Barley Mill Plaza 


. P.O. Box 80019 


Bloomington, DE 19880-0019 
(800) 237-2374 


ITT ElectroMechanical Components Worldwide 
1851 East Deere Avenue 

Santa Ana, CA 92705-6500 | 

(714) 261-5300 


ATT Microelectronics 
555 Union Blvd 
Allentown, PA 18103. 
(800) 372-2447 














Futurebus+ and Related Futurebus+ Users Groups and 
Standards Standards Associations 


P896.1 Futurebus+ Logical Layer Specifications VFEA International Trade Association (VITA) 
P896.2 Futurebus+ Physical Layer Specifications 10229 North Scottsdale Road 


: : Suite B 
Includes: Profiles A, B, D, F, M and T Scottsdale, AZ 85253-1437 USA 


P896.3 Futurebus + Systems Configuration Guide (602) 951-8866 

P896.4 Futurebus+ Conformance Test ; ; 

P1014.1 VME/Futurebus+ Bridge ie a and Users Group (FMUG) 
P1101.2 2mm Connector Specification Fleet, Hampshire GU13 8XU England 

P1101.3 Conduction Cooling Specification : 0252- 629937 


P1156 _ Environmental and Power Supply Specification 


-gouasajay TLa/ + snqeunyny 


Standards Department 


P1194, 1 Backplane Transceiver Logic (BTL) Specification IEEE Computer Society 


P1212 CSR Architecture 1730 Massachusetts Avenue, N.W., - 


P1296.2 MultibusII/Futurebus + Bridge Washington, D.C. 20036-1903 
ae in (202) 371-0101 


P1301 Metric Equipment Practice 

P1301.1 Futurebus+ Hard Metric Boards + 2mm Con- 
* nector 

P1394 High Speed Serial Bus 

P1596 . SCI (Scalable Coherent interface) 


All specifications/standards for Futurebus+ are available 
from either the IEEE or VITA. Please see user groups for 
information on how to contact these associations. 
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Glossary of Terms for Futurebus + 
(Listed Alphabetically) - 


ADDRESS ONLY TRANSACTION: A bus transaction that 
does not include a data phase. The only information trans- 
ferred is contained within the connection phase and, in 
some cases, the disconnection phase. 


APPLICATION ENVIRONMENT PROFILE (AEP): An appli- 
cation environment profile is a document that describes 
functional requirements and points to existing standards, 
selecting and binding options within those standards. An 
implementor who then designs a specific board and/or sys- 
tem SHOULD be reasonably assured that another design- 
er’s (manufacturer or supplier) boards will properly function 
within the same system. This includes all aspects of defini- 
tion: mechanical, electrical, protocol environmental, and 
system considerations. 


ARBITRATION: The process of selecting the next bus mas- 
ter. 


ARBITRATION MESSAGE: An event number broadcast on 
the arbitration bus to all modules on the bus. 


BACKPLANE: An electronic circuit board and connectors 
used to connect other boards together electrically. The 
backplane connects selected pins of the connectors, thus 
providing the medium for the transfer of signals needed for 
the operation of the bus. 


BACKPLANE BUS: A means to connect circuit modules 
using common signal! traces on a backplane and a standard 
set of rules. 


BEAT: An event that begins with the transition on a syn- 
chronization line by the master followed by the release of an 
acknowledge line by one or more slaves. Command and 
data information may be transferred from the master to one 
or more slaves in the first half of the beat. During the sec- 
ond half of the beat the slaves may transfer capability, 
status, and data information back to the master. 


BIU: The BIU (Bus Interface Unit) refers to the logic on a 
module that converts bus signals and the protocols to and 
from signals which are compatible with the functional logic 
of the module. 


BLOCK READ TRANSACTION: An address beat followed 
by a block of one or more data read transfers from a set of 
contiguous addresses beginning with the address in the ad- 
dress beat. This is terminated by the appropriate style of 
end beat. 

BLOCK WRITE TRANSACTION: An address beat followed 
by a block of one or more data write transfers to a set of 
contiguous addresses beginning with the address in the ad- 
dress beat. This is terminated by the appropriate style of 
end beat. 


Reprinted with permission of IEEE. 


BRIDGE: A bridge is a protocol converter and Control and 
Status Register Architecture (CSRA) unit which interfaces 
between two-or more buses. The buses may adhere to dif- 
ferent bus standards for mechanical, electrical:and logical 
operation (such as a bridge from Futurebus+ to VMEbus or 
to Multibus II). 


BUS TENURE: The duration of a master’s control of the 
bus; i.e., the total time that a module has the right to initiate 
bus transactions. 


BUS TRANSACTION: An event initiated with a connection 
phase and terminated with a disconnection phase. Data 
may or may not be transferred during a bus transaction. 


BUSY: If a slave cannot or should not accept a bus trans- 
action at that time it, or any other module, may issue a Busy 
status to the master of the transaction. The master must 
then release the bus. The master must relinquish the bus 
and may re-acquire and re-try the transaction after a suit- 
able time interval. 


BYTE LANE: A data path formed by eight data lines and 
one parity line used to carry a single byte among the system 
modules. 


CACHE COHERENCE: A system of caches is said to be 
coherent with respect to a cache line if each cache and 
main memory in the coherence domain observes all modifi- 
cations of that same cache line. A modification is said to be 
observed by a cache when any subsequent read would re- 
turn the newly written value. 


CACHE MEMORY: A buffer memory inserted between one 
or more processors and the bus, used to hold currently ac- 
tive copies of blocks from main memory. Cache memories 
exploit spatial locality by what is brought into a cache. Tem- 
poral locality is exploited by what is removed from the 
cache. 


COHERENCE DOMAIN: A coherence domain is a region in 
a multiple-cache system inside which cache consistency 
measures are enforced. In a system which contains bus 
bridges, a coherence domain may or may not be extensible 
beyond the local bus through a bus bridge to remote buses. 
COHERENCE LINE: A data block for which cache consist- 
ency attributes are maintained. 

COMPETITOR: A module actively participating in the cur- 
rent control acquisition cycle of the arbitration process. 
CONNECTED SLAVE: A slave that is permitted to partici- 
pate actively in the data transfer handshake. A selected 
slave that is not disabled (including a diverted slave), a re- 
flecting slave, and an intervening slave are connected 
slaves. A disabled slave or, an unselected slave that is not 
intervening or reflecting, is not a connected slave... 


L 








CONNECTED TRANSACTION: A transaction in which both 
the request and response are performed within the same 
bus transaction. 


CONNECTION PHASE: A beat that begins with the asser- 
tion of the address synchronization line followed by the re- 
lease of an address acknowledge line. It is used to broad- 
cast the address and command information. Modules deter- 
mine whether they wish to take part in the transaction based 
on this information. 

CONTROL ACQUISITION: The total of all bus activity asso- 
ciated with acquiring exclusive control of the bus. 
COPYBACK CACHE: A cache memory scheme with the 
attribute that data written from the processor is normally 
written to the cache rather than the main memory. Modified 
data in the cache is written to the main memory when a 
cache line flush or replacement forces it to be written to 
main memory to avoid loss of the data. 

CSR: Control and Status Register. 

CSRA: Control and Status Register Architecture. 

DATA PHASE: A period within a transaction used to trans- 
fer data. 


DEADLOCK: Deadlock occurs when actors are waiting on 
actions that can only be performed by those waiting. 


DISABLED SLAVE: A selected slave that detects that an 
‘intervening slave ‘is: participating | in the data transfer in its 


dress- -only transaction and does not participate: inthe data 
transfer. phase. A slave may be disabled only during single- 
slave mode transactions. 


DISCONNECTION PHASE: A period within a transaction 
used to return the bus signals to their quiescent state. In 
addition, this phase might be used to transfer additional in- 
formation required to perform or abort the pfeauested opera- 
tion. 


DIVERTED SLAVE: A selected slave that detects that a 

"‘ saflectitig slave is participating in the data transfer in its 
place. A diverted slave participates in the transfer by read- 
ing the data being transferred between the master and the 
reflecting slave. A slave may be diverted only es single- 
slave mode transactions. 


DMA: A direct memory access architecture is an option ca- 
pability of an |1/O controller. After being started by the proc- 
essor, the I/O controller with DMA capabilities can access 
their commands, fetch data, and report status by accessing 
memory directly. 

DOUBLET: A set of two freem bytes. 

EMERGENCY MESSAGE: An arbitration cycle with a spe- 
cial high arbitration number, which is selected from a set of 
numbers assigned to emergency messages. 

ENTRANT: A live inserted module in the process of aligning 
itself with the arbitration protocol. 

FAIRNESS: A bus request protocol in which a module re- 
frains from acquiring the bus in order to allow other modules 
of the fairness class to use the bus. 

FORWARD PROGRESS: A module which is not blocked 
from performing the tasks necessary to achieve its goal is 
said to be making forward progress. Forward progress is 
guaranteed only in the absence of deadlock or starvation. 


FREE BYSTANDER: A free bystander can be a participat- 
ing slave that is no longer an entrant, or a potential master 
that has no current need to acquire the bus and is not fair- 
ness inhibited. 

GEOGRAPHICAL ADDRESS: A unique identifier statically 
assigned to each logical module slot on the bus and as- 
sumed by any module connected to that slot. 

INACTIVE MODULES: This category contains all the mod- 
ules that have no need to participate in the control acquisi- 
tion process in any way. 

INHIBITED BYSTANDER: An inhibited bystander is a po- 
tential master that has no current need to acquire the bus 
and is fairness inhibited. 
INTERVENING SLAVE: An unselected slave that disables 
the selected slave and replaces that selected slave with 
itself. Intervening slaves can operate only during single- 
slave mode transactions. 

LIVE INSERTION: Insertion of boards into a backplane can 
be performed when power is OFF or when power is ON. The 
process of inserting or withdrawing boards into and from a 
backplane when power is ON is referred to as ‘‘Live Inser- 
tion”. 

LIVELOCK: Livelock is a metastable situation in which 
some modules acquire and release resources in a way that 
none of them make progress. 

LOCKING: A facility whereby a module is requested to guar- 
antee exclusive access to addressed data, blocking other 
modules from accessing that data. This allows indivisible 
operations to be performed on addressed resources. 


MASTER: A module which has acquired control of the bus 
through the control acquisition procedure. 

MASTER ELECT: A master elect is the module that has 
won the arbitration process and is waiting for the master to 
transfer control to it. 

MIXED TRANSACTION: An address beat followed by any 
number or combination of data write and data read transfers 
to a single location using the single address transfer mode. 
This is terminated by the appropriate style of end beat. 


MODULE: A collection of circuitry designed to perform 
Futurebus+ operations. 


MONARCH PROCESSOR: A monarch processor, or simply 
the monarch, is the processor selected to manage the con- 
figuration and initialization of all modules on that logical bus. 
A grand monarch is a processor selected to direct the con- 
figuration and initialization of an entire system with multiple 
interconnected logical buses. 
NODE: A node is a set of contro! registers addresses (in- 
cluding identification-ROM and reset command register), 
which are initially defined in a 4k-byte (minimum) initial node 
address space. Each node can be reset independently. 
OCTLET: A set of eight adjacent bytes. 

PACKET DATA TRANSFER PROTOCOL: A very fast but 
technology dependent non-compelied transfer mechanism 
which uses a compelled protocol over the entire packet to 
provide flow control. 

PARALLEL CONTENTION ARBITRATION: A process 
whereby modules assert their unique arbitration number of a 
parallel bus and release signals according to an algorithm 
such that after a period of time the winner's number ap- 
pears on the bus. 
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PARKING: The process whereby the master retains control 
of the bus without actively using in. Parking typically occurs 
when no other module has requested the bus. The idle bus 
arbitration mechanism may be used when the bus is parked. 


PARTICIPATING SLAVE: A participating slave may be in 
any of these states; 1) entrant, 2) bystander. 


PORT: A port is the interconnection of a bus bridge to a bus. 
From the point of view of a particular node on a bus,.the 
node connects to the local port of a bus bridge, while ports 
to other buses connected to the same bus bridge are called 
remote ports. 


POTENTIAL MASTER: A potential master is a 1 module that 
is capable of participating in the contro! acquisition process 
and taking full control of the bus. A potential master may be 
in any of these states; 1) entrant, 2) free bystander, 3) inhib- 
ited bystander, 4) competitor, 5) withholder, 6) master elect, 
7) master, 8) recompeting master. 

POTENTIAL SLAVE: A module that i is capable of being ad- 
dressed by and is able to carry out transactions with the 
master. 

PRIORITY: A bus request protocol in which the module with 
the highest arbitration number acquires the bus. 
PREEMPTION: Preemption occurs when the arbitration pro- 
cess is restarted after a master elect has been chosen in 
order to allow a high priority module to jump the queue. 


QUADLET: A set of four adjacent bytes. 


‘“RECOMPETING MASTER: The module that is in control of 


the bus and has initiated a control acquisition procedure i in 
order to unlock slave interfaces. 


REFLECTING SLAVE: An unselected slave that forces the 
selected slave into a write only mode. In read transfers the 
reflecting slave substitutes itself for the selected slave in 
providing data while causing the selected slave to store the 
data that appears on the bus. In write transfers the reflect- 
ing slave copies the data into itself as-well as the selected 
slave.. Reflecting slaves can ee only during single- 
slave mode transactions. 


REPOSITORY OF LAST RESORT: In a cache-based envi- 
ronment, the repository of last resort of shared data is.a 
physical storage location that is the ultimate source and 
destination of the datum that is shared. 


REQUEST: A request .is a command generated by a re- 
quester, to initiate an action on a responder. For a proces- 
sor-to-memory read transaction, for example, the request 
transfers the memory address and command from the proc- 
essor to memory. In the case of.a split transaction the re- 
quest would be a separate bus transaction. In the case of a 
connected transaction the request would be the connection 
phase of a bus transaction. 

REQUESTER: A transaction initiated by a module sending a 


request (containing address, command, and sometimes 
data). This module is referred to as the requester. 


RESPONDER: A transaction is completed by a module 


sending a response (containing the completion status and 
sometimes data). 


RESPONSE: A reply generated by a responder, to complete 
a transaction initiated by a requester. For a processor-to- 
memory read transaction, for example, the response returns 


the case of a “Split transaction the response would be a sep- 
arate bus transaction. In the case of a connected transac- 
tion the response would be the data and disconnection 
phases of a bus transaction. 


ROUND ROBIN: An arbitration mode where, after a module 
acquires and uses the bus, it must then wait until all other 
modules currently requesting the bus at the same priority 
level have had a chance to use the bus. 


SELECTED SLAVE: A potential slave that has been select- 
ed by the master because it recognized its address on the 
bus lines during an address transfer, and will become a con- 
nected slave, unless an intervening slave Preven it from 
becoming so. 


SHARED MEMORY: The address space in the system ac- 
cessible to all caching modules. 


SKEW: The difference between the propagation delays of 
two or more signals passing through Lid paths in a de- 

x 
SLAVE: A module that can be Be addressed arid is cope of 
participating in bus transactions. 


SNARF: A module is said to snarf a transaction if it takes a 
copy of data passing by on the bus even though it did not 
request it. 


SNOOP: A module is said to snoop a fansacion if it is not 
the master that originated the transaction or the repository 
of last resort for the data, but it still monitors the transaction. 
Cache memories snoop transactions to maintain coher- 
ence. 

SPATIAL LOCALITY: The tendency for a program to refer- 
ence closely related clusters of memory addresses over 
short time, intervals. 

SPLIT TRANSACTION: An operation in which the request 
is transmitted in one bus transaction and the response is 


transmitted in a separate subsequent bus transaction. 


STARVATION: A system condition which occurs when one 
or more modules perform no useful work for an indefinite 
period -of time due to lack of access to the. bus or other 
system resources. 


STRONG SEQUENTIAL CONSISTENCY: A system is 
strong sequentially consistent if each cache in the system 
observes all modifications to all cache lines in the same 
order. 


TEMPORAL LOCALITY: The tendency for a program to ref- 
erence the same memory locations over short time inter- 
vals:: c 


TRANSFER LINE SIZE: The size of the block of data trans- 
ferred to or.from main memory in a caching environment. 


UNSELECTED SLAVE: A potential slave module that does 
not recognize its moarers on the bus guing an address 
transfer. 


WEAK SEQUENTIAL CONSISTENCY: A system exhibits 
weak sequential consistency if references to global syn- 
chronizing variables are strong sequential consistency, and 
if no reference to a synchronizing variable is issued by any 
processor until all previous modifications to global data 
have been observed by all caches, and if no reference to 
global data is issued by any processor until all previous 
modifications to synchronizing variables have been ob- 
served by all caches. 


WITHHOLDER: A withhoider is a potential master that re- 
quires control of the bus module and is fairness inhibited. 
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28 Terminal Ceramic Leadless Chip Carrier (E) 
NS Package Number E28A 


0.065 —0.076 


7] [7 (1-651=1.930 


BOTTOM 
_ VIEW 


E28A (REV C) 


20 Lead Ceramic Dual-In-Line Package (J) 
NS Package Number J20A 


0.025 
(0.635) 


(5.588 — 7.874) 


eres 0h gn oe ope 


0.005 —0.020. 
(0.127 -0. (0.127 —0.508) 


RAD TYP 0.037 +0.005 
(0.940+0.127) 
0.005 0.055 +0.005 


—_—— a <|— 
0.290-0.320 . (1.397 + 0.127) 0.020 —0.060 
a GLASS SEALANT (0.508 — 1.524) 


B6° 94° 0.150 
0.008— 0.012 (3.810) 0.125—0.200 
(0.203 —0.305) , MIN (3.175-5.080) 


|___0.310-0.410 0.310—0.410 0.060 0.018+0.003 
(7.874—10.41) (1. (824 (0.457 20.076) 
BOTH nine 0.100+0.010 


(2.540 0.254) 
J20A (REV M) 
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Physical Dimensions 


28 Lead Ceramic Dual-In-Line Package (J) 
NS Package Number J28B 


0.600 
(15.24) 
MAX GLASS 


0.571-0.583 0.025 


(14.50 14.81) (0.635) 
: |AD 


0.030 —0.055 
(0.762 — 1.397} 
RAD 


GLASS 

SEALANT 
0.590—0.620 

(14.99 —15.75) { 


0.020 -—0.070 


) an 


9s +5° 


+0.025 

0.685 0.060 

0.635 

(10 ise) 
0,008 0.012 


(0.203 -0.305) 





0.225 rf 
5715) 
ui 


MAX > ag — 2.055 + 0.005. 005 
*~ 11.39740.127) 397+0.127) 
0.060- nie: = eg — 0.1000. 0.100 + 0.010 0.0180. 0.018 +0.002 


(1,524 ~ 2.540) mS (2.540£0.254) 54020. ay 10.457 = 0.051) 45740. lel : 
J28B (REV C) 


20 Lead Molded Dual-In-Line Package (N) 
NS Package Number N20A | 


0.092 x 0.030 
(2.337 X 0.762) 
MAX OP 


aia a 
MIN 


0.300-0.320 
(7.620-8.128) 


= 
Lt 


0.009--0.015 
ari 381) 


0.325 _ 4) 015 


+1.016 
(o2s5 0381 





0. 0.060 +0.005 
+0,040 (1.52420.127) 127) 


0.100.010 ; 
aad b carseos || 


1.013-1.040' 
(25.73-26.42) 
0.0320.005 
(0.81320.127) 
RAD 


OPTION 2 


OPTION 2 


(3.302 0.127) 


0.145-0.200 
(3.683-5.080) © 


90° 0.004° : 
0.020 
0.125-0.140 (0.508) 


ee, (3.175-3.556) - MIN 
(0.457 0.076) 


N20A (REV G) 








20 Lead Plastic Chip Carrier (V) 
NS Package Number V20A 


4 SPACES AT 
0.050 


(1.270) 


4 
“4 SPACES AT 
0.050 
(1.270) 


0.310 -0.330 
* (1.874 ~8.382) 
{CONTACT DIMENSION) 


0.026-0.032 _| 
(0.660 -0.813) 
TYP 


0.008 -—0.015 


(0.127 —0.381) 
0.104—0.118 


(2.642 —2.097) 
(8.890) 
REF SO 

0.385 -0.395 


(9.779 — 10.03) 


SQUARE 


44 Lead Plastic Chip Carrier (V) 
NS Package Number V44A 


(15,49 — 16.00) 
0.032 0.040 0.020 SQUARE ; | 
0.813—1.016) (0.508) (CONTACT DIMENSION) 
MAX Mi 


ts > or een + , 


0.005 0.015 
(0.127-0.381) 
MAX 


0.013-0.018 
(0.330 —0.457) 


WP o.020 
(0.508) 
MIN 


0.032 0.040 
(0.813 - 1.016) 


0.165 —0.180 
(4.191 4.572} 


V20A (REV J} 


0.165—0.180 


0.013-0.018 (4.191— 4.872) 


0.026 —0.032 0.104 —-0.118 
{0.660 fad (2.642 -—2.997) 


V44A (REV H) 
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68 Lead Plastic Chip Carrier (V) 
NS Package Number V68A 


0.020, 
0.050= 0.800 (0.508) 
(1.270 = 20.32) MIN © 
16 SPACES AT 0.104—0.118 
(2.642 —2.997) 


Physical Dimensions 


0,013—0.018 


(0.330 —0.457) 
0.910 -0.930 | Tye 


(23.11—23.62) 


0.985 — 0.995 
(25.02 — 25.27) 
SQUARE 


(1.270 = 20.32) 
16 SPACES AT 


DIMENSION 
18° 


(8.382) 
DIA NOM 
PEDESTAL 


all 


(~~ 
Ls 


( 
} 


(0.813 —1.016) 


0,185 —0.180 
0.005 —0.015 (4.191 — 4.872) 
‘(0.127 -0.881) ; 


V68A (REV G) 


44 Lead Plastic Quad Flatpak (VF) 
NS Package Number VF44B 


012.40 + 0.40: 
(10.00 £ 0.10 


4 5 MAX 
SEE DETAIL E 1 6 tt ai a EJECTOR MARK . 
70.2 MAX : . a -0.05 < A, A < 0.15 
BOTTOM EJECTOR MARK 
, 0.3 40.1 TYP 


a DETAIL E 
| 00.20)/ Cc] A-B© | ©) TYPICAL, SCALE: 30X 


13° TYP 


; ‘ Sho 


7 
cc i 3 
1.20 TYP", . ‘0 a) | |. 0°-7° TYP 





0.25 MIN TYP 0.80 £0.05 
0.58 £0.20 TYP 








28 Lead Ceramic Flatpak (W) 
NS Package Number W28B 


0.042 + 0.005 


fs: 


(1.067 + 0,127) 


0.003+0.001 
(0.127 40.025) 
(NOTE 2) 


0.090. 
(2. 72.286) " 


0.030 + 0.001 001 1 
{0.762 0.025) 625) 


(NOTE 3) 


0.0075 -0.0105 


(0.1905 —-0.2667) 


0.421+0.009, 
' {10.69 £0.229) 


- 


0.390+0.002 
{9.908 £0.051) 
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NOTES: UNLESS OTHERWISE SPECIFIED 


NOTE 1. LEAD FINISH: SOLDER DIPPED WITH Sn60 OR $n63 SOLDER CON- 
FORMING TO MIL-M-38510 TO A MINIMUM THICKNESS OF 200 
MICROINCHES (5.08 MICROMETER). SOLDER MAY BE APPLIED 
OVER LEAD BASIS METAL OR Sn PLATE. 


0.218 £0,010, NOTE 2. LEAD THICKNESS MAY BE INCREASED BY 0.003 INCHES (0.08mm). 
(5.537 £0.254) MAXIMUM AFTER LEAD FINISH 1S APPLIED, 


NOTE 3. LEAD 1 IOENTIFICATION SHALL BE: 
8) ANOTCH OR OTHER IDENTIFICATION MARK 
WITHIN THIS AREA, OR 
b) A TAB ON CEAD 1, EITHER SIDE. 
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0.53820.006 — 0.974+0,005 
(13.6740.152)  (24.74£0,127) 


gi 
+ 


0.006 + 0.002 | 
(0.152 £0.051) 


DETAIL A 
(NOTE 3) 


W28B {REV Ay 
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